Formatting of negative durations

[chrishens]

Hello,

I am trying to format a negative duration using Luxon. Specifically, I have a duration of -1.5 hours, and I would like to display it as -01:30. However, when I use the following code:

Duration.fromObject({ hours: -1.5 }).toFormat("hh:mm")

I get the output -01:-30 instead of the desired -01:30.

Could someone please help me understand how to correctly format a negative duration in this case (assuming this is possible)?

Thank you!

[dobon]

I have looked into this and agree that it is buggy behavior. I think we should patch this, but maybe that would be breaking for some people, so I'll leave that decision to leadership. I can't imagine how this behavior would be useful to anyone as-is.

It is not that pretty, but for practical purposes, you can suppress the negative sign using Intl.NumberFormat options, namely signDisplay, and then use additional logic to re-add the negative sign where you want it when applicable. eg:

const t = -1.5;
const signlessDuration = Duration.fromObject({ hours: t }).toFormat("hh:mm", {signDisplay: "never"});
return ((t < 0) ? "-" : "" ) + signlessDuration;

[diesieben07]

This is not necessarily desired for all durations. For example, -3 hours and 2 minutes might make people think the minutes are positive.
Therefor this will have to be behind an option, for example called leadingSignOnly.

Duration.fromObject({hours: -1.5}).toFormat('hh:mm'); // -01:-30 as before
Duration.fromObject({hours: -1.5}).toFormat('hh:mm', { leadingSignOnly: true }); // -01:30

What do you think?

[chrishens]

But isn't "T" already used as a formatting character for localized 24 hour time?

[diesieben07]

That's for DateTime.toFormat. Duration.toFormat uses a different set of tokens.

[chrishens]

I understand. I was just trying to avoid confusion. But following your logic you could opt for just using "T" for Duration.toFormat and omit the "hh:mm". This would then represent the duration as hh:mm in your desired locale with the appropriate "-" sign if the duration is negative. Just a thought.

[diesieben07]

Intl.DurationFormat is a very new API that has just arrived in browsers. Hence it is not supported by Luxon yet.
Luxon has Duration.toHuman which does something similar using Intl.NumberFormat.

I just looked at what Intl.DurationFormat does and it always only outputs a leading -, no matter the format. For example it will output '-1 hour, 30 minutes'.
With that, I think I have come around to changing toFormat to only adding a negative sign to the largest unit. A PR would be appreciated!

[dobon]

I've implemented a patch for this in a pull request: #1701

Any feedback or review is appreciated.

[diesieben07]

After further consideration I have decided not to enable this behavior by default.
Instead the next version will have a parameter to toFormat to enable this new behavior:

Duration.fromObject({ hours: -1.5 }).toFormat("hh:mm", { signMode: "negativeLargestOnly" }): // => -01:30

[shaedrich]

Thanks for implementing this 👍🏻 However, this is quite a mouthful, especially if this is the project's default and used quite a lot. Do you plan on making this globally configurable via luxon.Settings and/or the object constructor config argument?

[diesieben07]

For the moment I would recommend writing your own helper function.

The way Durations work currently is quite unfortunate and is the source of much frustration.

• Mixed signs in Durations are confusing at best and produce bad results at worst.
• Floating point numbers in Durations cause all kinds of problems.
• Allowing Duration Math on calendar units without a reference point is always going to produce bad results.

I am planning to deprecate all three of these things in the next release, logging warnings if they happen. The next major version of Luxon will then remove them. Once that is done, "signMode: negativeLargestOnly" would become obsolete, because there are no more mixed-sign Durations and it can become the default.

I am sorry that this probably is not the satisfactory answer you're looking for, but breaking changes like this require a bit of lead time.

[shaedrich]

I am sorry that this probably is not the satisfactory answer you're looking for

Well, yes and no actually: I'd say, it's definitely a step in the right direction—and as you say: "but breaking changes like this require a bit of lead time."

So, yeah, I'm happy that you want to tackle this in general. Maybe, in the major release after the next major release, there will be a solution implemented for one or more of these three options once people had time to follow-up on the deprecation warnings 👍🏻

[diesieben07]

It will be the next major release that should bring these improvements.
I plan to do the deprecation warnings for the next feature release (with a flag to turn them off for the time being), this way people can prepare their code before the major version.

So:

1. In the next Luxon 3.x release I am planning to log deprecation warnings for
   • Duration creation with fractional numbers
   • Duration creation with mixed signs
   • Duration math being done with conversionAccuracy or matrix parameter used
   • Duration math being done with calendar units of variable length where the conversion is inaccurate without a calendar reference.
   • Option in Settings to control deprecation warnings.
   • Optionally, not sure how feasible this is yet, maybe in a Luxon 3.y version: A Settings switch to opt-in to the new Duration behavior
2. In Luxon 4.0.0:
   • Situations above will turn into errors.
   • Duration behavior will be improved thanks to the constraints.

I have one other big breaking change in mind for Luxon 4. I am planning to do a writeup of the plans in a pinned Issue soon.