fix(date): NaN-revive setters seed from raw +0, not LocalTime(0) (#4927)#5055
Merged
Conversation
Date.prototype.setFullYear step 2 substitutes t = +0 for a NaN time value WITHOUT applying LocalTime — the seed components are the raw UTC +0 reading (1970-01-01 00:00:00). js_date_apply_setter substituted 0.0 before calling rebuild_local_with, which then decoded the epoch through timestamp_to_local_components, picking up the 1970 epoch's local offset: a CET process revived new Date(NaN).setFullYear(2020) to local 01:00 (test expected 00:00), and TZ=America/New_York landed on Dec 31 19:00. CI (TZ=UTC) never saw it. Pass the NaN through instead — both rebuild_with and rebuild_local_with already implement the spec's NaN branch (seed 1970/0/1 00:00:00, revive only when a year override is present).
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
1 participant
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.
Fixes #4927.
Root cause
Narrower than the issue's suspicion: the local→UTC conversion in
rebuild_local_withalready computes the offset at the target instant, and DST-crossing setters on valid dates were already correct. The actual bug was the Invalid-Date revive path: ECMA-262Date.prototype.setFullYearstep 2 substitutest = +0for a NaN time value without applyingLocalTime— the seed components are raw UTC +0 (1970-01-01 00:00:00).js_date_apply_settersubstitutedbase = 0.0before calling the rebuild, which then decoded the epoch throughtimestamp_to_local_components, picking up the 1970 epoch's local offset: CET revivednew Date(NaN).setFullYear(2020)to local 01:00;TZ=America/New_Yorklanded on 2020-12-31 19:00.TZ=UTC(CI) was unaffected — exactly the reported green-CI/red-laptop split.Fix
Pass the NaN time value through to
rebuild_with/rebuild_local_with— both already implement the spec's NaN branch (seed1970/0/1 00:00:00, revive only when a year override is present, reassemble as local + offset-at-target). One substitution line removed.Validation
date::tests::test_full_year_setters_revive_invalid_date_onlynow passes underTZ=UTC,America/New_York,Australia/Sydney,Europe/Amsterdam(previously failed everywhere but UTC); fulldate::group green under all four.node --experimental-strip-types, byte-identical in all four TZs: NaN revive (local + UTC),setMonthacross DST boundaries both directions,setFullYearfrom a year-end timestamp, local constructors in Jan/Jul (getTimechecked),setHoursacross the year.Code-only PR — version bump + changelog left for merge time.