Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6fd438a4aef274513546006638ff58275695eaa4
https://github.com/WebKit/WebKit/commit/6fd438a4aef274513546006638ff58275695eaa4
Author: Yijia Huang <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
A JSTests/stress/temporal-zdt-dst-gap-epoch-limits.js
M Source/JavaScriptCore/runtime/temporal/core/TimeZoneICUBridge.cpp
Log Message:
-----------
[JSC][Temporal] Resolve DST gaps through GetPossibleEpochNanoseconds so the
epoch range check is not skipped
https://bugs.webkit.org/show_bug.cgi?id=321102
rdar://184140083
Reviewed by Yusuke Suzuki.
Temporal.ZonedDateTime.from("+275760-10-05T02:30[Australia/Sydney]") produced a
live
ZonedDateTime whose [[EpochNanoseconds]] was outside the ±8.64e21 limit: Sydney
springs
forward on the first Sunday in October, and that gap is past the maximum epoch.
DisambiguatePossibleEpochNanoseconds resolves a gap by shifting the local time
and
re-entering GetPossibleEpochNanoseconds (steps 16.e and 22), which range-checks
it in its
own step 5. We computed the shifted instant as naiveNs - offsetBefore instead —
value-equivalent but not throw-equivalent, and the only guard on this path,
since a gap
leaves step 4's per-candidate loop nothing to check. Latent until 318635@main
replaced
TemporalZonedDateTime::tryCreate's release-mode isValid() throw with
CreateTemporalZonedDateTime step 1's ASSERT.
Steps 14-25 are now literal, which also fixes the candidate selection (16.g
returns
possibleEpochNs[0], 25 returns possibleEpochNs[n - 1]). Steps 6-13 stay folded
into the
FORMER/LATTER probe in getNamedTimeZoneEpochNanoseconds, as temporal_rs does;
those steps
cannot throw, so skipping them loses nothing observable.
Test: JSTests/stress/temporal-zdt-dst-gap-epoch-limits.js
Canonical link: https://commits.webkit.org/318663@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
