Duration.formatTo returns incoherent values for duration of more than a year

[florianOA-db]

Describe the bug
Duration.formatTo returns incoherent values for durations of more than a year.

To Reproduce

Duration.fromObject({ 
    milliseconds: Duration.fromObject({ years: 1, months: 2, days: 3 }).as('milliseconds')
}).toFormat('yyyy MM dd hh:mm:ss');
// returns '0001 02 08 00:00:00'
// there is 5 too many days

Duration.fromObject({ 
    milliseconds: Duration.fromObject({ years: 1, months: 2, days: 3 }).as('milliseconds')
}).shiftTo('year').toFormat('yyyy MM dd hh:mm:ss');
// returns 0001 02 02 03:17:15
// this is not even close to the expected value, from where do all those hours and minutes come from ?

Actual vs Expected behavior
The value expected from those 2 calls is 0001 02 03 00:00:00

Desktop (please complete the following information):

• OS: Windows
• Browser Chrome 141
• Luxon version 3.7.2
• Your timezone Europe/Paris

Additional context
This worked fine before version 3.4.2

[diesieben07]

Date units (year, month, day, etc.) are not the same length. A day for example could be 23, 24 or 25 hours depending on daylight savings time. A month can be 28, 29, 30 or 31 days long. A year can be 365 or 366 years long.
Duration has no idea which year/month/day you are talking about, hence it has to use "reasonable defaults". For example, a month is always considered to be 30 days long, a day is always considered to be 24 hours long.

When you convert to milliseconds, you lose the information that this was 1 year, 2 months and 3 days. Then you use toFormat and ask Luxon to format this millisecond value as a years, months, days, hours minutes and seconds. It now has to convert back to those units and this conversion is inherently lossy for the reasons outlined above.

See also this section in the docs: https://moment.github.io/luxon/#/math?id=duration-math

This worked fine before version 3.4.2

It is doubtful it actually worked fine. In previous versions, the underlying shiftTo function worked differently, but it was broken in different ways. This is just a fundamentally unsolvable problem, because the question "How many days is 25 hours?" cannot be answered.

It is on my roadmap for Luxon 4 to revamp this aspect of durations entirely, making such ambiguous conversions illegal.

[florianOA-db]

Thanks for the answer, i understand that durations can be hard to convert from a unit to another unit and that choices must be made. But I think the choice made here could be improved, heres' why :

> Duration.fromObject({ milliseconds: Duration.fromObject({ years: 1 }).as('milliseconds') }).toFormat('M dd');
'12 05'

Kind of expected, i can understand that 1 year = 365 days = 12 months of 30 days + 5days

> Duration.fromObject({ milliseconds: Duration.fromObject({ years: 1 }).as('milliseconds') }).toFormat('y dd');
'1 00'

Clearly expected : 365 days = 1 year

> Duration.fromObject({ milliseconds: Duration.fromObject({ years: 1 }).as('milliseconds') }).toFormat('y M dd');
'1 0 05'

That's where i'm lost : In the format i clearly state i want years, and expect the same result as the previous example (1year 0months 0days). But Luxon here chooses to have 12 months of 30 days, instead of 1 year of 365 days. When I include y in the format, I expect Luxon to preserve the year component (365 days) instead of converting it into 12 months of 30 days. Is this intentional ?

The .shiftTo('year') was my attempt at hinting Luxon that i wanted 365 days per year, but it kind of failed.

[diesieben07]

In all your examples you are creating a Duration but then immediately converting it to milliseconds. This loses information. When you do Duration.fromObject({ years: 1}).as('milliseconds') the information that it was based on years is lost. The resulting Duration only has a millisecond value.

So when you then format that Duration as a different set of units, Luxon basically has to guess on what you actually meant, because a day is not always 24 hours, a month is not always 30 days, etc.

I would really recommend only converting Duration units very intentionally and if at all possible give the correct units from the very beginning. For example, when creating a Duration from two DateTimes, create it in the correct set of units already, because then you cannot get the wrong answer.

These conversions will not be allowed in Luxon 4 for this very reason, they are confusing. In Luxon 4 if you attempt to format a Duration with only milliseconds in it as "days, months and years" you will get an error, because this is an ambiguous conversion.