3

It looks like Safari's implementation of Int.DateTimeFormat assumes that the second Sunday in March will ALWAYS be the DST time cutoff which is not correct as prior to 2007 it was the first Sunday in April. It also appears that this affects the other end as well when DST ends. PS: This code is being run in Indiana, USA which is in the eastern time zone (GMT-4)

More specifically...

  • 2007 and newer: correctly for all dates.
  • 2006: incorrectly for dates between the second Sunday in March and first Sunday in April, and between the last Sunday in October and the first Sunday in November.
  • 2005 and older: incorrectly for all dates between the second Sunday in March and first Sunday in November.

Here's a little JSBin that outlines the exact dates where this becomes an issue (note it all works correctly on every browser but safari) https://jsbin.com/mayadehowu/edit?js,output

var formatter = new Intl.DateTimeFormat('en');
var date = new Date('6/2/2005');
console.log(formatter.format(date)); // => outputs "6/1/2005"

I dug in further and it may be due to this change in the ECMA specifications.

Has anyone else encountered this problem? If so what were your solutions to work around this? I need a fix, but I am skeptical to patch over a safari-specific bug by adding an hour in specific cases because if Safari fixes this then our logic will be broken again.

razorcat
  • 73
  • 7
  • The parts of the specification relate to entire implementations, they don't mean dates will be treated differently when different specification were in force by individual implementations. I.e. they should behave one way or the other, not both. PS `new Date('6/2/2005')` is a less than ideal way to create a date. Far better to use `new Date(2005, 5, 2)`. – RobG May 21 '19 at 20:36
  • You should include the geographic location being used for the host system and the daylight saving rules that have been used in the applicable timezone. – RobG May 21 '19 at 20:42
  • I understand your point regarding the specifications. I may be wrong, but I brought it up because it appears as though Safari may actually have different internal implementations of the specs. For example `new Date(2005, 5, 7)` in Safari appears correctly as `Tue Jun 07 2005 00:00:00 GMT-0400 (EDT) `, but calling Intl.DateTimeFormat's format on that date in my location (en-US) returns `6/6/2005` which tells me the date parse and Intl formatter are assuming different implementations. And good point about the date creation, I sometimes forget locales when making quick demonstration examples. – razorcat May 22 '19 at 13:20
  • Did you find a good workaround/fix for this issue? I'm encountering the exact same problem. My app uses lots of historical dates and Intl.DateTimeFormat in Safari (and ONLY Safari) gets it wrong for certain dates-- like Sep 1, 1850. `new Date(1850,9,1)` is correct but `new Intl.DateTimeFormat().format(new Date(1850,9,1))` returns Aug 31, 1850. Also interesting... Chrome/Firefox show different UTC offsets vs Safari for this date so there might be more than just a formatting issue. – Howard Burrows Aug 07 '19 at 15:22
  • I opened up a Safari bug ticket with Apple at the same time I opened this SO topic and they have had no real response other than the automated responses... And no I've had no workarounds currently. I considered hacking it by detecting the cases and tweaking the dates in safari, but that would mean it would break if Apple happens to fix this bug. There's a similar thread about this that I just found [here](https://stackoverflow.com/questions/16946002/javascript-time-zone-is-wrong-for-past-daylight-saving-time-transition-rules/16951442#16951442) – razorcat Aug 08 '19 at 14:28
  • 1
    [This appears to be fixed in 14](https://developer.apple.com/documentation/safari-release-notes/safari-14_1-release-notes#JavaScript-and-WebAssembly) – NathanQ Jul 08 '21 at 18:27

1 Answers1

0

This was finally fixed in Safari 14.1 per @NathanQ's comment

razorcat
  • 73
  • 7