17

Safari on OSX believes that October 6th, 2013 is a Saturday in Australia. It's not, it's actually a Sunday.

To replicate this issue, just set your time zone to Sydney-Australia, pop open the dev console in Safari, and enter new Date("2013/10/06"). You'll get this:

enter image description here

Now change to Seattle-US and you'll get this:

enter image description here

The problem also occurs for Melbourne-Australia but not for cities further north such as Brisbane (which fits the zoning for Australian DST), or a handful of other cities I've tested throughout the world.

Now, it just so happens that October 6th, 2013 is the start of daylight savings time in Sydney.. And the same mistake is made for the other DST start dates in other years. There does not seem to be a problem for DST end dates. There does not seem to be a problem for DST start dates in PDT time zone. Also, Chrome and Firefox do not exhibit this problem.

I've tested most of this on two different Macs, one on Snow Leopard with Safari 5.1.7 and one on Lion with Safari 6.0.2.

So the question is -- is this a bug or is there some kind of rational reason for this?

Improve this question
8
  • 1
    Same behaviour on Safari under Win7 for me
    – koopajah
    Commented Feb 12, 2013 at 18:37
  • Try: d = new Date("2013-10-06"); d.setMinutes(d.getMinutes() + d.getTimezoneOffset())
    – Dagg Nabbit
    Commented Feb 13, 2013 at 22:33
  • My hack is to use new Date(datestring+" 12:00").getDay() which puts the time solidly in the middle of the day away from all DST switches (worldtimezone.com/daylight.html).
    – jwl
    Commented Feb 13, 2013 at 22:44
  • @jlarson do you have any more info on this / link to the bug filed with Apple?? I'm unfortunately seeing the same issue with Safari on both OSX Mavericks and iOS7...
    – Boycs
    Commented Feb 24, 2014 at 4:10
  • @Boycs it is problem ID #13201479. I don't see a way from thier bug reporter to get a direct link but it should come up by search. (ugh, Apple's developer web stuff is still so *@!#)
    – jwl
    Commented Feb 24, 2014 at 16:09

1 Answer 1

Reset to default
7

This really should be considered a bug - Technically speaking DST in Sydney starts on 2013/10/06 at 2AM, so 2AM then becomes 3AM (http://www.timeanddate.com/worldclock/clockchange.html?n=240). It appears Safari in this case is thinking you mean 2013/10/06 at midnight - and is then going back 1 hour to 11PM the previous day. This doesn't even make sense because at 2AM the clock is supposed to go forward an hour.

I would recommend filing a bug report for this - because the output is so obviously wrong

https://developer.apple.com/bugreporter/

Improve this answer
5
  • 1
    Yep, I have filed a bug report. The biggest reason I put it on SO is so that any other Dev trying to figure it out may have an easier time of running into this information...
    – jwl
    Commented Feb 13, 2013 at 22:42
  • @jlarson Do you have any info from Apple when this bug will be fixed? I can reproduce it on Safari 7.1 and 8.0. Thanks.
    – dherbolt
    Commented Sep 22, 2014 at 8:49
  • 1
    I think, it is reported to Webkit Dev team: bugs.webkit.org/show_bug.cgi?id=4930
    – dherbolt
    Commented Sep 25, 2014 at 9:53
  • 2
    Proper Webkit bug describing this behavior: bugs.webkit.org/show_bug.cgi?id=137003
    – dherbolt
    Commented Oct 1, 2014 at 4:34
  • I have the same problem with Amman/Jordan. If your system time is outside of DST, and you make a date object within DST, the offset is not applied and you're behind a few hours. Sometimes this results in the wrong day being constructed.
    – Daniel Lizik
    Commented Jan 29, 2019 at 9:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.