Repository navigation
Conversation
Transition searches never looked before 1847-01-01, the lower bound shared
with proposal-temporal's polyfill, but the time zone database has earlier
transitions: Asia/Manila, Pacific/Guam, Pacific/Saipan, Pacific/Palau and
Pacific/Kosrae moved across the date line on 1844-12-31. From 1800,
getTimeZoneTransition('next') skipped them for the 1899 or 1900 change, and
from 1846 'previous' found nothing.
Lower the bound to 1844-01-01. Offsets themselves were already right; only
the transition searches were cut off.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke
Transition searches never look before 1847-01-01, but five zones change their offset on 1844-12-31, when they moved across the date line: Asia/Manila, Pacific/Guam, Pacific/Saipan, Pacific/Palau and Pacific/Kosrae. These are the only transitions before 1847 among the 418 zones of Node 26.12 (tz 2026e). Their offsets are correct, but
getTimeZoneTransition()misses them: from 1800,'next'skips to the 1899 or 1900 change, and from 1846,'previous'returnsnull.nextfrom 1800previousfrom 1846nullnullnullnullnullWhy
minPossibleTransitionSec(1847-01-01, the bound proposal-temporal's polyfill uses asBEFORE_FIRST_DST) is where forward searches from the far past start, and below which backward searches give up.The fix
Lower
minPossibleTransitionSecto 1844-01-01. Only searches that start before 1847 are affected.Tests
Added to
polyfill/src/internal/timeZoneImpl.test.ts: Manila from 1800 forwards and from 1846 backwards, and Guam from 1800. Manila's transition instant depends on the host's time zone data: Node 22.14 (tz 2024b) gives Manila's local mean time as −15:56, newer data as −15:56:08, so the test accepts 1844-12-31T15:56:00Z through 15:56:08Z and checks that both directions agree.Verification
With pnpm 10 and the repo's
use-node-version(Node 22.14.0), aftergit submodule update --init --recursive:pnpm run build,pnpm run tsc:allandpnpm run lint: cleanpnpm run vitest: 939 passed, 7 skipped; the new test also passes withVITEST_NODE_VERSION=26.12.0. On 26.12, twodiffUnzonedparity tests fail onmainas well.pnpm run test262: full 6843 passed, 46 expected failures; basic 5324 passed, 1565 expected failures (the same asmain)dist/implementation.jsmatches native Temporal for every row of the table above.