Bug 11157 – REGRESSION (r16780): Date conversion to local time gets the DST flag wrong for some dates

• Component: JavaScriptCore
• Status: RESOLVED LATER

See bug 5514.

The "compute DST flag based on a year which starts on the same day" doesn't work for all cases, so it shouldn't be used on platforms that support negative time_t, such as Mac.

To see the regression, set your computer's time zone to New Zealand and open the attached test case, which is a variation on the test from bug 5514. It's weird that the original test didn't regress. It might point to a bug in the new implementation of the hack.

Created attachment 10911 [details]
Test case

[Kevin McCullough]

fixed with r16798.  Will commit test case as a layout test

Still failing in TOT.

Created attachment 10951 [details]
A test that fails in the Jerusalem timezone as of r16855

[Kevin McCullough]

<rdar://4777813>

There are several issues here:
1) Dates that shouldn't exist: for example 
April 25th 1982 2:30am Pacific
because DST happens exactly at 2am, it skipps to 3am and 2:30am should never happen

2) Dates that happen twice: for example
Oct 31, 1982 1:30am PST/PDT
because DST makes 2am go back to 1am, the hour from 1am to 2am will happen twice

3) The History of DST: Some locations did not observer DST for some times (as seen by the command zdump)

Here is a summary of our resolutions
3) According to the spec, history should not take into account what really happened but interpolate from a comparable year, where comparable years are judged by when Jan 1 happens and if the year is a leap year.
This will only happen for dates that fall outside of the 1970-2038 range. if you fall out of that range then you are offset to a comparable year.
This is consistent with what most browsers.

2) To address dates that happen twice, the standard behavior is to pick Standard Time (or the second time the time happens)

1) The final issue is what to do with times that should not have happened.  Some browsers just show the time and some subtract an hour (e.g. 2am becomes 1am).  What we think should happen is that an hour should be added (e.g. 2am becomes 3am).  This has been added as a bug in Radar (number is at the top of this comment)