Bug 11157 - REGRESSION (r16780): Date conversion to local time gets the DST flag wrong for some dates
Summary: REGRESSION (r16780): Date conversion to local time gets the DST flag wrong fo...
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2006-10-04 12:33 PDT by mitz
Modified: 2006-10-11 12:47 PDT (History)
1 user (show)

See Also:


Attachments
Test case (989 bytes, text/html)
2006-10-04 12:34 PDT, mitz
no flags Details
A test that fails in the Jerusalem timezone as of r16855 (857 bytes, text/html)
2006-10-06 12:07 PDT, mitz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-10-04 12:33:51 PDT
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.
Comment 1 mitz 2006-10-04 12:34:21 PDT
Created attachment 10911 [details]
Test case
Comment 2 Kevin McCullough 2006-10-05 10:16:21 PDT
fixed with r16798.  Will commit test case as a layout test
Comment 3 mitz 2006-10-05 10:52:24 PDT
Still failing in TOT.
Comment 4 mitz 2006-10-06 12:07:40 PDT
Created attachment 10951 [details]
A test that fails in the Jerusalem timezone as of r16855
Comment 5 Kevin McCullough 2006-10-11 12:47:25 PDT
<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)