Skip to content

Find the time zone transitions of 1844 - #114

Open
gesposito wants to merge 1 commit into
fullcalendar:mainfrom
gesposito:fix-transitions-before-1847
Open

gesposito wants to merge 1 commit into
fullcalendar:mainfrom
gesposito:fix-transitions-before-1847

Conversation

@gesposito

Copy link
Copy Markdown

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' returns null.

Zone Native next from 1800 temporal-polyfill 1.0.6 Native previous from 1846 temporal-polyfill 1.0.6
Asia/Manila 1844-12-31T15:56:08Z 1899-09-06T04:00:00Z 1844-12-31T15:56:08Z null
Pacific/Guam 1844-12-31T14:21:00Z 1900-12-31T14:21:00Z 1844-12-31T14:21:00Z null
Pacific/Saipan 1844-12-31T14:21:00Z 1900-12-31T14:21:00Z 1844-12-31T14:21:00Z null
Pacific/Palau 1844-12-31T15:02:04Z 1900-12-31T15:02:04Z 1844-12-31T15:02:04Z null
Pacific/Kosrae 1844-12-31T13:08:04Z 1900-12-31T13:08:04Z 1844-12-31T13:08:04Z null
import { Temporal } from 'temporal-polyfill/implementation'

Temporal.Instant.from('1800-01-01T00:00Z')
  .toZonedDateTimeISO('Asia/Manila')
  .getTimeZoneTransition('next')
  .toString()
// '1899-09-06T12:00:00+08:00[Asia/Manila]', expected '1845-01-01T00:00:00+08:04[Asia/Manila]'

Why

minPossibleTransitionSec (1847-01-01, the bound proposal-temporal's polyfill uses as BEFORE_FIRST_DST) is where forward searches from the far past start, and below which backward searches give up.

The fix

Lower minPossibleTransitionSec to 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), after git submodule update --init --recursive:

  • pnpm run build, pnpm run tsc:all and pnpm run lint: clean
  • pnpm run vitest: 939 passed, 7 skipped; the new test also passes with VITEST_NODE_VERSION=26.12.0. On 26.12, two diffUnzoned parity tests fail on main as well.
  • pnpm run test262: full 6843 passed, 46 expected failures; basic 5324 passed, 1565 expected failures (the same as main)
  • The built dist/implementation.js matches native Temporal for every row of the table above.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant