Can't create `ZonedDateTime` corresponding to time zone edge cases

[fabon-f]

Temporal.ZonedDateTime.from("2000-10-08T01:00:00-01:00[America/Noronha]"); // Uncaught RangeError: Invalid TimeZone offset
Temporal.ZonedDateTime.from("2000-10-08T03:00:00-03:00[America/Boa_Vista]"); // same error

I believe the root cause is same to an upstream issue (tc39/proposal-temporal#3110). Searching a next offset transition with the window of 60 days can overlook an offset transition when offset transitions occurred twice within 60 days (which is pretty common in the history, even after 1970).

[fabon-f]

temporal-polyfill/packages/temporal-polyfill/src/internal/timeZoneNative.ts

Lines 140 to 152 in bc1baf3

	function getOffsetSec(epochSec: number): number {
	const clampedEpochSec = clampNumber(epochSec, minTransition, maxTransition)
	const [startEpochSec, endEpochSec] = computePeriod(clampedEpochSec)
	const startOffsetSec = getSample(startEpochSec)
	const endOffsetSec = getSample(endEpochSec)
	if (startOffsetSec === endOffsetSec) {
	return startOffsetSec
	}
	const split = getSplit(startEpochSec, endEpochSec)
	return pinch(split, startOffsetSec, endOffsetSec, epochSec)
	}

I don't understand the original intention of this part (perhaps memoization?), but apparently these lines introduced the bug. I verified that rewriting the getOffsetSec like below will fix this bug:

function getOffsetSec(epochSec: number): number {
  return getSample(epochSec)
}

Binary search for offset transition is fundamentally unreliable because two offset transitions can occur in the given period and there's no way to detect such undesirable situation from polyfill, and narrowing the window (currently 60 days) is just a superficial solution for this bug. I believe getting offset from epoch sec and time zone is what the polyfill can do and should do in a reliable way.

[arshaw]

confirmed. @fabon-f, you're right the root cause is similar to tc39/proposal-temporal#3110, basically having overly narrow windows from which you look for DST transitions.

As you know, the recreation you posted doesn't involve .getTimeZoneTransition, but is still related. Internally, we cache the information about time zone transitions and use it to derive offsets more performantly. Instead of querying Intl.DateTimeFormat. each time.

I'll need to design a more robust algorithm for both to solve this bug.

[fabon-f]

I noticed that #49 is a bug with the same root cause (because of an unreliable result of getOffsetSec).

new Date('2100-08-01').toLocaleString('en',{timeZone:'Europe/London',timeStyle:'long'});
// '1:00:00 AM GMT+1' in Node.js
Temporal.ZonedDateTime.from('2100-08-01[Europe/London]').offset;
// should be '+01:00' but '+00:00'