161623 2016-09-06 03:57:45 -0700 toLocaleDateString() resolves incorrect date for some old dates 2020-12-17 15:48:26 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Mac OS X 10.11 RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=218604 InRadar P2 Normal --- 219915 1 medikoo+webkit.org ysuzuki andy commit-queue eric ggaren joren.broekema rniwa webkit-bug-importer ysuzuki oldest_to_newest 1226642 0 medikoo+webkit.org 2016-09-06 03:57:45 -0700 Running following: (new Date(1969, 8, 26)).toLocaleDateString() Results with: "9/25/1969" While it should result with: "9/26/1969" It goes up to around 1977: > (new Date(1977, 8, 26)).toLocaleDateString() < "9/25/1977" > (new Date(1978, 8, 26)).toLocaleDateString() < "9/26/1978" Same issue affects V8, although it gets dates after 1970 right -> https://bugs.chromium.org/p/v8/issues/detail?id=5353 No such issue is observed on Firefox. 1445744 1 andy 2018-07-27 10:40:22 -0700 This appears to be working now. Please reopen with additional details, like your local timezone, if you are continuing to see this issue. 1446170 2 medikoo+webkit.org 2018-07-30 00:36:09 -0700 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)) 1446199 3 andy 2018-07-30 07:06:32 -0700 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. 1446200 4 medikoo+webkit.org 2018-07-30 07:07:57 -0700 Sorry I forgot to mention: I'm in Warsaw/Poland so CET timezone 1446344 5 andy 2018-07-30 13:57:18 -0700 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 1446345 6 andy 2018-07-30 13:57:53 -0700 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." 1446471 7 andy 2018-07-30 20:07:35 -0700 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. 1623416 8 joren.broekema 2020-02-27 04:45:56 -0800 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. 1625466 9 joren.broekema 2020-03-04 02:34:46 -0800 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. 1704769 10 ysuzuki 2020-11-05 00:47:36 -0800 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. 1704772 11 ysuzuki 2020-11-05 01:00:14 -0800 (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. 1704774 12 ysuzuki 2020-11-05 01:01:02 -0800 (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 1704777 13 413271 ysuzuki 2020-11-05 01:04:10 -0800 Created attachment 413271 Patch 1704778 14 413272 ysuzuki 2020-11-05 01:06:32 -0800 Created attachment 413272 Patch 1705113 15 ews-feeder 2020-11-05 20:19:01 -0800 Committed r269502: <https://trac.webkit.org/changeset/269502> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413272. 1705115 16 webkit-bug-importer 2020-11-05 20:20:22 -0800 <rdar://problem/71105838> 1714891 17 commit-queue 2020-12-15 13:20:20 -0800 Re-opened since this is blocked by bug 219915 1715574 18 eric 2020-12-17 15:02:29 -0800 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. 1715591 19 ysuzuki 2020-12-17 15:41:20 -0800 (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. 1715592 20 ysuzuki 2020-12-17 15:41:45 -0800 The reverted patch is once integrated since we workaround ICU missing API issue differently. 1715596 21 eric 2020-12-17 15:46:23 -0800 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. 1715600 22 ysuzuki 2020-12-17 15:48:26 -0800 (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 413271 2020-11-05 01:04:10 -0800 2020-11-05 01:06:31 -0800 Patch bug-161623-20201105010409.patch text/plain 1703 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjY5NDE5CmRpZmYgLS1naXQgYS9KU1Rlc3RzL0NoYW5nZUxv ZyBiL0pTVGVzdHMvQ2hhbmdlTG9nCmluZGV4IDJhNGY5YTY5YjdmODMzZWM2Y2JhYzkyOWVlMzcy ZjQ3NTQ3MjZjOGMuLmRlYTE1ZGVjYWEzNGZkZWNkNjA3NDYwMjJjMGVlZTI1YTEzYWY1MWUgMTAw NjQ0Ci0tLSBhL0pTVGVzdHMvQ2hhbmdlTG9nCisrKyBiL0pTVGVzdHMvQ2hhbmdlTG9nCkBAIC0x LDMgKzEsMTQgQEAKKzIwMjAtMTEtMDUgIFl1c3VrZSBTdXp1a2kgIDx5c3V6dWtpQGFwcGxlLmNv bT4KKworICAgICAgICB0b0xvY2FsZURhdGVTdHJpbmcoKSByZXNvbHZlcyBpbmNvcnJlY3QgZGF0 ZSBmb3Igc29tZSBvbGQgZGF0ZXMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hv d19idWcuY2dpP2lkPTE2MTYyMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEp LgorCisgICAgICAgICogY29tcGxleC55YW1sOgorICAgICAgICAqIGNvbXBsZXgvdGltZXpvbmUt b2Zmc2V0LWFuZC1kc3QtaW4td2Fyc2F3LmpzOiBBZGRlZC4KKyAgICAgICAgKHNob3VsZEJlKToK KwogMjAyMC0xMS0wMyAgU2FhbSBCYXJhdGkgIDxzYmFyYXRpQGFwcGxlLmNvbT4KIAogICAgICAg ICBBZGQgYmFjayB0aGUgcmVtb3ZlZCBhc3NlcnRpb24gZnJvbSByMjY5MzM4IGFuZCBhZGQgYSB0 ZXN0CmRpZmYgLS1naXQgYS9KU1Rlc3RzL2NvbXBsZXgueWFtbCBiL0pTVGVzdHMvY29tcGxleC55 YW1sCmluZGV4IDI4ZWZmMWZmZWVhZWI2OGJjZTgxYjg5OWZhMjViZGE3MGJiOTA0MzUuLjRlMWNm YTNmMTdkMzgwMDU1MmI1ODAwMWRiMTE5MzRjM2IxYjJkNWIgMTAwNjQ0Ci0tLSBhL0pTVGVzdHMv Y29tcGxleC55YW1sCisrKyBiL0pTVGVzdHMvY29tcGxleC55YW1sCkBAIC0zNCwzICszNCw2IEBA CiAKIC0gcGF0aDogY29tcGxleC90aW1lem9uZS1vZmZzZXQtYmVmb3JlLWFtZXJpY2EtbG9zLWFu Z2VsZXMtaXMtZGVmaW5lZC5qcwogICBjbWQ6IHJ1bkNvbXBsZXhUZXN0IFtdLCBbXSwgIlRaPUFt ZXJpY2EvTG9zX0FuZ2VsZXMiLCAiLS11c2VEb2xsYXJWTT0xIgorCistIHBhdGg6IGNvbXBsZXgv dGltZXpvbmUtb2Zmc2V0LWFuZC1kc3QtaW4td2Fyc2F3LmpzCisgIGNtZDogcnVuQ29tcGxleFRl c3QgW10sIFtdLCAiVFo9RXVyb3BlL1dhcnNhdyIsICItLXVzZURvbGxhclZNPTEiCmRpZmYgLS1n aXQgYS9KU1Rlc3RzL2NvbXBsZXgvdGltZXpvbmUtb2Zmc2V0LWFuZC1kc3QtaW4td2Fyc2F3Lmpz IGIvSlNUZXN0cy9jb21wbGV4L3RpbWV6b25lLW9mZnNldC1hbmQtZHN0LWluLXdhcnNhdy5qcwpu ZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwLi5hNWZmYzdjMTQxNDAxOGY0YWQ2YmNjNDk3ZTMyYmI1MjQzYTlmM2E0Ci0tLSAv ZGV2L251bGwKKysrIGIvSlNUZXN0cy9jb21wbGV4L3RpbWV6b25lLW9mZnNldC1hbmQtZHN0LWlu LXdhcnNhdy5qcwpAQCAtMCwwICsxLDYgQEAKK2Z1bmN0aW9uIHNob3VsZEJlKGFjdHVhbCwgZXhw ZWN0ZWQpIHsKKyAgICBpZiAoYWN0dWFsICE9PSBleHBlY3RlZCkKKyAgICAgICAgdGhyb3cgbmV3 IEVycm9yKCdiYWQgdmFsdWU6ICcgKyBhY3R1YWwpOworfQorCitzaG91bGRCZSgobmV3IERhdGUo MTk2OSwgOCwgMjYpKS50b0xvY2FsZURhdGVTdHJpbmcoKSwgYDkvMjYvMTk2OWApOwo= 413272 2020-11-05 01:06:32 -0800 2020-11-05 20:19:02 -0800 Patch bug-161623-20201105010631.patch text/plain 1927 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjY5NDE5CmRpZmYgLS1naXQgYS9KU1Rlc3RzL0NoYW5nZUxv ZyBiL0pTVGVzdHMvQ2hhbmdlTG9nCmluZGV4IDJhNGY5YTY5YjdmODMzZWM2Y2JhYzkyOWVlMzcy ZjQ3NTQ3MjZjOGMuLjZjMzliZjFhNmQyZTRhM2ZkZWI3Y2JkMzdkNmNkN2U2ZWJjMmY3ODQgMTAw NjQ0Ci0tLSBhL0pTVGVzdHMvQ2hhbmdlTG9nCisrKyBiL0pTVGVzdHMvQ2hhbmdlTG9nCkBAIC0x LDMgKzEsMTcgQEAKKzIwMjAtMTEtMDUgIFl1c3VrZSBTdXp1a2kgIDx5c3V6dWtpQGFwcGxlLmNv bT4KKworICAgICAgICB0b0xvY2FsZURhdGVTdHJpbmcoKSByZXNvbHZlcyBpbmNvcnJlY3QgZGF0 ZSBmb3Igc29tZSBvbGQgZGF0ZXMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hv d19idWcuY2dpP2lkPTE2MTYyMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEp LgorCisgICAgICAgIFRoZSBpc3N1ZSBpcyB0aGF0IHRpbWV6b25lIG9mZnNldCBpbiBvbGQgV2Fy c2F3IGRhdGUgd2FzIGJyb2tlbiBiZWNhdXNlIGBsb2NhbHRpbWVfcmAncyB0emRhdGEgaXMgYnJv a2VuLgorICAgICAgICBUaGUgaXNzdWUgaXRzZWxmIHdhcyBmaXhlZCBpbiByMjE4MzQ4LiBUaGlz IHBhdGNoIGFkZHMgYW5vdGhlciB0ZXN0IGNhc2UgdG8gZW5zdXJlIHRoaXMgaXMgZml4ZWQuCisK KyAgICAgICAgKiBjb21wbGV4LnlhbWw6CisgICAgICAgICogY29tcGxleC90aW1lem9uZS1vZmZz ZXQtYW5kLWRzdC1pbi13YXJzYXcuanM6IEFkZGVkLgorICAgICAgICAoc2hvdWxkQmUpOgorCiAy MDIwLTExLTAzICBTYWFtIEJhcmF0aSAgPHNiYXJhdGlAYXBwbGUuY29tPgogCiAgICAgICAgIEFk ZCBiYWNrIHRoZSByZW1vdmVkIGFzc2VydGlvbiBmcm9tIHIyNjkzMzggYW5kIGFkZCBhIHRlc3QK ZGlmZiAtLWdpdCBhL0pTVGVzdHMvY29tcGxleC55YW1sIGIvSlNUZXN0cy9jb21wbGV4LnlhbWwK aW5kZXggMjhlZmYxZmZlZWFlYjY4YmNlODFiODk5ZmEyNWJkYTcwYmI5MDQzNS4uNGUxY2ZhM2Yx N2QzODAwNTUyYjU4MDAxZGIxMTkzNGMzYjFiMmQ1YiAxMDA2NDQKLS0tIGEvSlNUZXN0cy9jb21w bGV4LnlhbWwKKysrIGIvSlNUZXN0cy9jb21wbGV4LnlhbWwKQEAgLTM0LDMgKzM0LDYgQEAKIAog LSBwYXRoOiBjb21wbGV4L3RpbWV6b25lLW9mZnNldC1iZWZvcmUtYW1lcmljYS1sb3MtYW5nZWxl cy1pcy1kZWZpbmVkLmpzCiAgIGNtZDogcnVuQ29tcGxleFRlc3QgW10sIFtdLCAiVFo9QW1lcmlj YS9Mb3NfQW5nZWxlcyIsICItLXVzZURvbGxhclZNPTEiCisKKy0gcGF0aDogY29tcGxleC90aW1l em9uZS1vZmZzZXQtYW5kLWRzdC1pbi13YXJzYXcuanMKKyAgY21kOiBydW5Db21wbGV4VGVzdCBb XSwgW10sICJUWj1FdXJvcGUvV2Fyc2F3IiwgIi0tdXNlRG9sbGFyVk09MSIKZGlmZiAtLWdpdCBh L0pTVGVzdHMvY29tcGxleC90aW1lem9uZS1vZmZzZXQtYW5kLWRzdC1pbi13YXJzYXcuanMgYi9K U1Rlc3RzL2NvbXBsZXgvdGltZXpvbmUtb2Zmc2V0LWFuZC1kc3QtaW4td2Fyc2F3LmpzCm5ldyBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAuLmE1ZmZjN2MxNDE0MDE4ZjRhZDZiY2M0OTdlMzJiYjUyNDNhOWYzYTQKLS0tIC9kZXYv bnVsbAorKysgYi9KU1Rlc3RzL2NvbXBsZXgvdGltZXpvbmUtb2Zmc2V0LWFuZC1kc3QtaW4td2Fy c2F3LmpzCkBAIC0wLDAgKzEsNiBAQAorZnVuY3Rpb24gc2hvdWxkQmUoYWN0dWFsLCBleHBlY3Rl ZCkgeworICAgIGlmIChhY3R1YWwgIT09IGV4cGVjdGVkKQorICAgICAgICB0aHJvdyBuZXcgRXJy b3IoJ2JhZCB2YWx1ZTogJyArIGFjdHVhbCk7Cit9CisKK3Nob3VsZEJlKChuZXcgRGF0ZSgxOTY5 LCA4LCAyNikpLnRvTG9jYWxlRGF0ZVN0cmluZygpLCBgOS8yNi8xOTY5YCk7Cg==