Duration::total incorrect result with DST

[arshaw]

Duration::total is mishandling DST gaps with unit is 'day'

I realized this when running this test failing for my polyfill. Portable recreation:

var hours25 = new Temporal.Duration(0, 0, 0, 0, 25);
var relativeTo = Temporal.ZonedDateTime.from("2024-03-09T02:30[America/New_York]")
var totalDays = hours25.total({ unit: "days", relativeTo })
// ACTUAL: 1.0416666666666667 (1 + 1 / 24)
// EXPECTED: 1.043478260869565216 (1 + 1 / 23)

// why EXPECTED?
{
  var start = relativeTo.add({ days: 1 }) // 2024-03-10T03:30:00-04:00[America/New_York]
  var middle = relativeTo.add(hours25) // 2024-03-10T04:30:00-04:00[America/New_York]
  var end = relativeTo.add({ days: 2 }) // 2024-03-11T02:30:00-04:00[America/New_York]
  console.log(
    'EXPECTED:',
    1 +
    Number(middle.epochNanoseconds - start.epochNanoseconds) /
      Number(end.epochNanoseconds - start.epochNanoseconds)
  ) // 1.043478260869565216
  console.log(
    'hours in day:',
    Number(end.epochNanoseconds - start.epochNanoseconds) /
      3600000000000
  ) // 23
}

// why ACTUAL?
{
  var start = relativeTo.add({ days: 1 }) // 2024-03-10T03:30:00-04:00[America/New_York]
  var middle = relativeTo.add(hours25) // 2024-03-10T04:30:00-04:00[America/New_York]
  var end = start.add({ days: 1 }) // 2024-03-11T02:30:00-04:00[America/New_York]
  //             ^incorrect. should not be added to start. instead, base off relativeTo
  console.log(
    'ACTUAL:',
    1 +
    Number(middle.epochNanoseconds - start.epochNanoseconds) /
      Number(end.epochNanoseconds - start.epochNanoseconds)
  ) // 1.0416666666666667
}

The problem is happening here:

proposal-temporal/polyfill/lib/ecmascript.mjs

Lines 3312 to 3319 in 1c9ddf5

	let oneDayFarther = AddDaysToZonedDateTime(
	relativeResult.instant,
	relativeResult.dateTime,
	timeZoneRec,
	calendar,
	sign
	);
	let dayLengthNs = TimeDuration.fromEpochNsDiff(oneDayFarther.epochNs, relativeResult.epochNs);

I'd recommend reworking the Duration::total() system. This should happen while handling the reworks suggested in #2792.

[ptomato]

OK, I buy this explanation. The correct answer seems like 1+1/23 and that is also what results from the algorithm we are discussing in #2792. I still need to look at a few other cases though.

[ptomato]

Addressed as part of @arshaw's review comments on #2758.