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?

jwl
  • 10,268
  • 14
  • 53
  • 91
  • 1
    Same behaviour on Safari under Win7 for me – koopajah Feb 12 '13 at 18:37
  • Try: `d = new Date("2013-10-06"); d.setMinutes(d.getMinutes() + d.getTimezoneOffset())` – Dagg Nabbit Feb 13 '13 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 (http://www.worldtimezone.com/daylight.html). – jwl Feb 13 '13 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 Feb 24 '14 at 04: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 Feb 24 '14 at 16:09
  • Thanks @jlarson. Did you manage to come up with an effective workaround?? – Boycs Feb 24 '14 at 19:49
  • @Boycs see my comment from Feb 13 '13 above – jwl Feb 24 '14 at 21:47
  • Same with NZDT `> new Date(2014,8,28)` `< Sat Sep 27 2014 23:00:00 GMT+1200 (NZST)` – toxaq Sep 03 '14 at 05:39

1 Answers1

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/

codefactor
  • 1,616
  • 2
  • 18
  • 41
  • 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 Feb 13 '13 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 Sep 22 '14 at 08:49
  • 1
    I think, it is reported to Webkit Dev team: https://bugs.webkit.org/show_bug.cgi?id=4930 – dherbolt Sep 25 '14 at 09:53
  • 2
    Proper Webkit bug describing this behavior: https://bugs.webkit.org/show_bug.cgi?id=137003 – dherbolt Oct 01 '14 at 04: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 Jan 29 '19 at 09:09