Bug 161623

This appears to be working now. Please reopen with additional details, like your local timezone, if you are continuing to see this issue.

Bug still exists (nothing changed actually) We still can observe following output: > (new Date(1977, 8, 26)).toLocaleDateString() > "9/25/1977" In latest: - Safari Technology Preview (Release 61 (Safari 12.0, WebKit 13606.1.25.1)) - WebKit build archives(Version 11.1.2 (13605.3.8, 607+) - macOS release (Version 11.1.2 (13605.3.8))

Can you please run the following and comment the output here? new Intl.DateTimeFormat().resolvedOptions().timeZone new Date(1969, 8, 26).getTimezoneOffset() That would be really helpful for me tracking down the issue, since it works properly in my time zone.

Sorry I forgot to mention: I'm in Warsaw/Poland so CET timezone

k, I was able to successfully reproduce the issue by setting my mac to Warsaw time. new Intl.DateTimeFormat().resolvedOptions().timeZone // "Europe/Warsaw" new Date(1977, 8, 26) // Mon Sep 26 1977 00:00:00 GMT+0200 (CEST) new Date(1969, 8, 26).getTimezoneOffset() // -120 (new Date(1977, 8, 26)).toLocaleDateString('en', { hour: 'numeric', minute: 'numeric' }) // "9/25/1977, 11:00 PM" (new Date(1977, 8, 26, 1)).toLocaleDateString('en', { hour: 'numeric', minute: 'numeric' }) // "9/26/1977, 12:00 AM" So the locale formatter timezone ends up an hour different than Date constructor. Chrome and Firefox differ from Safari in the date constructor behavior: new Date(1977, 8, 26).getTimezoneOffset() Chrome, Firefox: -60 Safari: -120 new Date(1977, 8, 26).getTime() Chrome, Firefox: 244076400000 Safari: 244072800000

There is some code that tries to work around using actually accurate DST information, because the ECMAScript spec specifies that behavior. https://www.ecma-international.org/ecma-262/5.1/index.html#sec-15.9.1.8 "The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round." The ES2015 spec appears to change that expectation: https://www.ecma-international.org/ecma-262/6.0/index.html#sec-daylight-saving-time-adjustment And the latest drafts make it pretty explicit that historically accurate timezones should be used. https://tc39.github.io/ecma262/#sec-local-time-zone-adjustment "The local political rules for standard time and daylight saving time in effect at *t* should be used to determine the result in the way specified in the following three paragraphs."

Since this isn't just a toLocaleString issue, but a date timezone offset issue, it'd probably be best if someone else took a look at it. My naive attempt to simply remove the likely offending code caused a bunch of other issues I'm not sure how to handle.

I think I was able to reproduce this bug on Safari 13.0.5 for MacOS Mojave 10.14.6, but with Intl.DateTimeFormat. console.log(new Intl.DateTimeFormat('en-GB').format(new Date('12/06/1939'))); Results in 11/06/1939. So 1 day off. Strangely, anything between year 1940 and 1945 formats correctly. Then for 1946 up until 1976 it is off by 1 again. 1977 and onwards it seems to be correct, but I didn't check for all values so not 100% sure there.

I looked a bit further. https://en.wikipedia.org/wiki/Daylight_saving_time#History gives some background on why this is happening for certain years. Also, I don't think Intl is at fault, I have issues with the native Date parsing process > new Date('1939-12-06') < Wed Dec 06 1939 01:00:00 GMT+0100 (CET) > new Date('12/06/1939') < Wed Dec 06 1939 00:00:00 GMT+0100 (CET) So it parses it differently based on how you supply the date string.

This is because OS `localtime_r`'s timezone information is broken, and it is the same in Linux etc. This is fixed by using ICU TimeZone instead in bug 218348.

(In reply to Joren Broekema from comment #9) > I looked a bit further. > https://en.wikipedia.org/wiki/Daylight_saving_time#History gives some > background on why this is happening for certain years. Also, I don't think > Intl is at fault, I have issues with the native Date parsing process > > > new Date('1939-12-06') > < Wed Dec 06 1939 01:00:00 GMT+0100 (CET) > > > new Date('12/06/1939') > < Wed Dec 06 1939 00:00:00 GMT+0100 (CET) > > So it parses it differently based on how you supply the date string. This is different issue from this bug. I think one format is parsed as local time, an the other is parsed UTC.

(In reply to Yusuke Suzuki from comment #11) > (In reply to Joren Broekema from comment #9) > > I looked a bit further. > > https://en.wikipedia.org/wiki/Daylight_saving_time#History gives some > > background on why this is happening for certain years. Also, I don't think > > Intl is at fault, I have issues with the native Date parsing process > > > > > new Date('1939-12-06') > > < Wed Dec 06 1939 01:00:00 GMT+0100 (CET) > > > > > new Date('12/06/1939') > > < Wed Dec 06 1939 00:00:00 GMT+0100 (CET) > > > > So it parses it differently based on how you supply the date string. > > This is different issue from this bug. I think one format is parsed as local > time, an the other is parsed UTC. https://bugs.webkit.org/show_bug.cgi?id=218604

Created attachment 413271 [details] Patch

Created attachment 413272 [details] Patch

Committed r269502: <https://trac.webkit.org/changeset/269502> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413272 [details].

<rdar://problem/71105838>

Re-opened since this is blocked by bug 219915

The patch landed for this appears to only address issues with Europe/Warsaw dates. I'm experiencing an issue like this in Safari 14.0.2 (15610.3.7.1.10, 15610) however in America/New_York with some relatively more recent dates. Some examples: Wrong: new Date(1983, 2, 27).toLocaleDateString('en-US') -> "3/26/1983" new Date(1983, 3, 15).toLocaleDateString('en-US') -> "4/14/1983" new Date(1983, 3, 24).toLocaleDateString('en-US') -> "4/23/1983" Correct: new Date(1983, 0, 27).toLocaleDateString('en-US') -> "1/27/1983" new Date(1983, 1, 27).toLocaleDateString('en-US') -> "2/27/1983" new Date(1983, 3, 27).toLocaleDateString('en-US') -> "3/27/1983" new Date(1983, 3, 25).toLocaleDateString('en-US') -> "4/25/1983" Significantly, US DST in 1983 started April 24.

(In reply to Eric Casthart from comment #18) > The patch landed for this appears to only address issues with Europe/Warsaw > dates. I'm experiencing an issue like this in Safari 14.0.2 (15610.3.7.1.10, > 15610) however in America/New_York with some relatively more recent dates. > Some examples: > > Wrong: > > new Date(1983, 2, 27).toLocaleDateString('en-US') -> "3/26/1983" > new Date(1983, 3, 15).toLocaleDateString('en-US') -> "4/14/1983" > new Date(1983, 3, 24).toLocaleDateString('en-US') -> "4/23/1983" > > Correct: > > new Date(1983, 0, 27).toLocaleDateString('en-US') -> "1/27/1983" > new Date(1983, 1, 27).toLocaleDateString('en-US') -> "2/27/1983" > new Date(1983, 3, 27).toLocaleDateString('en-US') -> "3/27/1983" > new Date(1983, 3, 25).toLocaleDateString('en-US') -> "4/25/1983" > > Significantly, US DST in 1983 started April 24. Please test it with Safari Technology Preview :) Safari 14.0.2 does not include the patch.

The reverted patch is once integrated since we workaround ICU missing API issue differently.

Ahh, I didn't think to try it because the diff seemed specific to Warsaw. But I can confirm that the wrong examples I provided below are now working as expected with Technology Preview Release 117 (Safari 14.1, WebKit 15611.1.7.2). Thanks! (In reply to Yusuke Suzuki from comment #19) > (In reply to Eric Casthart from comment #18) > > The patch landed for this appears to only address issues with Europe/Warsaw > > dates. I'm experiencing an issue like this in Safari 14.0.2 (15610.3.7.1.10, > > 15610) however in America/New_York with some relatively more recent dates. > > Some examples: > > > > Wrong: > > > > new Date(1983, 2, 27).toLocaleDateString('en-US') -> "3/26/1983" > > new Date(1983, 3, 15).toLocaleDateString('en-US') -> "4/14/1983" > > new Date(1983, 3, 24).toLocaleDateString('en-US') -> "4/23/1983" > > > > Correct: > > > > new Date(1983, 0, 27).toLocaleDateString('en-US') -> "1/27/1983" > > new Date(1983, 1, 27).toLocaleDateString('en-US') -> "2/27/1983" > > new Date(1983, 3, 27).toLocaleDateString('en-US') -> "3/27/1983" > > new Date(1983, 3, 25).toLocaleDateString('en-US') -> "4/25/1983" > > > > Significantly, US DST in 1983 started April 24. > > Please test it with Safari Technology Preview :) > Safari 14.0.2 does not include the patch.

(In reply to Eric Casthart from comment #21) > Ahh, I didn't think to try it because the diff seemed specific to Warsaw. > But I can confirm that the wrong examples I provided below are now working > as expected with Technology Preview Release 117 (Safari 14.1, WebKit > 15611.1.7.2). > > Thanks! Awesome!!!!!! Thanks for testing :D