`Duration::round` with ZonedDateTime relativeTo conflicts with `ZonedDateTime::until` results

[arshaw]

Apologies for this rounding/diffing nitpicking. Repro:

const duration = new Temporal.Duration(1, 0, 0, 0, 24)
const past = Temporal.ZonedDateTime.from("2019-11-01T00:00[America/Vancouver]")
const future = past.add(duration)

const durationViaUntil = past.until(future, {
  largestUnit: 'years',
})
console.log(durationViaUntil.toString())
// "P1YT24H" (desired b/c of DST)

const durationViaRound = duration.round({
  largestUnit: 'years',
  relativeTo: past,
})
console.log(durationViaRound.toString())
// "P1Y1D" (undesired)

Precedents:

• ZonedDateTime::add adds Y/M/W/D before time parts
• ZonedDateTime::until diffs Y/M/W/D before time parts

It would make sense to have Duration::round effectively add Y/M/W/D to relativeTo before balancing time parts up to days (NanosecondsToDays). This is currently not possible because the Duration::round methods calls BalanceTimeDurationRelative before BalanceDateDurationRelative. (see here)

Encountered while working with this test:
intl402/Temporal/Duration/prototype/round/relativeto-string-datetime.js

Similar to:
#2563
#2715

[arshaw]

Another example, but this one related to halfExpand rounding and which 1-month window it's supposed to round within (I expect it to be shortened by 1 hour due to DST and round down, not up).

const duration = Temporal.Duration.from({ months: 1, days: 15, hours: 12 })
const past = Temporal.ZonedDateTime.from('2024-02-10T02:00[America/New_York]')
const future = past.add(duration)

const durationViaUntil = past.until(future, {
  smallestUnit: 'month',
})
console.log(durationViaUntil.toString())
// P1M (desired)

const durationViaRound = duration.round({
  smallestUnit: 'month',
  relativeTo: past,
})
console.log(durationViaRound.toString())
// P2M (undesired)

This also has implications for total:

Temporal.Duration.from({ months: 1, days: 15, hours: 12 }).total({
  unit: 'month',
  relativeTo: '2024-02-10T02:00[America/New_York]'
})
// actual: 1.5
// expected: 1.4986559139784945

[ptomato]

Thanks for the report. I've been investigating this and I agree that something seems wrong here. However, I'm not sure I agree with the suggested solution.

It would make sense to have Duration::round effectively add Y/M/W/D to relativeTo before balancing time parts up to days (NanosecondsToDays). This is currently not possible because the Duration::round methods calls BalanceTimeDurationRelative before BalanceDateDurationRelative. (see here)

Switching the order of BalanceDateDurationRelative and BalanceTimeDurationRelative would effectively revert #2508 which we already did to fix a different bug. It fixes the problem in the OP (the result becomes P1Y24H), but it brings back the other bug from #2508 (see largestunit-correct-rebalancing.js). It may be that we need to look elsewhere for the solution. Or it may be that these two weirdnesses are mutually exclusive, in which case we'd need to figure out which one is worse.

I suspect the problem in the second post is actually a different bug, occurring in a different place. I'll need to investigate that some more. FWIW, in that case the result from round() (P2M) seems like it's the expected one, and the until() result (P1M) seems incorrect. Reasoning, adding Y/M/W/D first:

• past + 1 month 15 days is on 2024-03-25, which is a 24-hour day, so 12 hours seems like it should be 0.5 days.
• past + 1 month is on 2024-03-10, which is a 31-day month, so 15.5 days seems like it should be 0.5 months.
• So past until future seems like it should be 1.5 months, which would round up to 2 months with half-expand rounding.

[ptomato]

I think I've tracked down the two discrepancies. The first one is addressed in #2758 (although as we discussed in the previous champions meeting, I'm still planning to add a refactor to that branch to make sure that round() and until() use the same code path)

The second discrepancy is actually not even a problem with round():

const duration = Temporal.Duration.from({ months: 1, days: 15, hours: 12 });
const past = Temporal.ZonedDateTime.from('2024-02-10T02:00[America/New_York]');
const future = past.add(duration);

duration  // => 1 month, 15 days, 12 hours
past.until(future, { largestUnit: 'months' })  // => 1 month, 15 days, 11 hours

This is because adding 1 month results in 2024-03-10T02:00[America/New_York] which is a nonexistent time, and so disambiguates to 03:00. This is technically the intended behaviour: the intermediate value between adding months and days must exist, though unfortunately this particular consequence makes it difficult to figure out what's happening. As it happens, though, we are currently discussing over at #2535 whether to change this.

Note that if you count in exact times, there is no discrepancy:

duration.round({ largestUnit: 'hours', relativeTo: past })  // => 1067 hours
past.until(future)  // => 1067 hours