| Issue 2131: | Selection bug when DST in Australia in Safari Mac | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Issue: Click on a selectable time slot in day view on specific date/time of 5th April 5pm-5:30pm, will incorrectly highlight cell 6pm-6:30pm (skips ahead 1 hour). Must be using MAC Safari web browser, and set timezone to Sydney, Australia (Australia eastern Daylight saving time). To Reproduce: 1) Change timezone to Sydney, Australia (Australia eastern Daylight saving time) if not already. (on OSX - System preferences > Date & Time > Time Zone Tab > Uncheck Set Timezone Automatically using current location > select Sydney, Australia from world map. (Location _must_ be Sydney, Australia it cannot be any other location because some other locations do not use daylight saving) 2) Load safari with url - http://jsfiddle.net/7PgLM/1/ 3) Click "day", change date to April 5th, then click time slot 5pm. The actual row selected will be incorrect and skip ahead 1 hour. 4) Also note, the popup alert within dayClick() callback is displaying a matching incorrect date. NOTE: - Date of 5th April is important as its change over of daylight saving - Must be using Mac Safari browser, safari on PC does not have bug, other browsers on mac do not have bug. (tested chrome, firefox) - Same problem using safari iPad and iPhone - Location _must_ be Sydney, Australia it cannot be any other location because some other locations do not use daylight saving
Apr 10, 2014
#1
pgbr...@gmail.com
Jun 7, 2014
(No comment was entered for this change.)
Status:
Reproducing
Labels: Type-Bug
Jun 11, 2014
I was able to reproduce this. A workaround is to use version 2 of fullcalendar with timezone:null http://jsfiddle.net/3E8nk/7/ (recreation when timezone:'local')
Summary:
Selection bug when DST in Australia in Safari Mac
(was: Click a timeslot on day view in Australia daylight saving region and wll incorectly select a timeslot 1 hour in future of the clicked slot - using Safari Mac only.)
Status: Accepted
Jun 12, 2014
I see what's going on here and it has to do with the way Safari represents dates during that strange period between 5pm and midnight on Apr 5 2014. The Date object is fundamentally flawed. See how the DST coercion is going wrong. Here is what is happening in my Safari JS console: > new Date(2014,3,5,21,0,0).toString() "Sat Apr 05 2014 22:00:00 GMT+1100 (EST)" > new Date(2014,3,5,22,0,0).toString() "Sat Apr 05 2014 23:00:00 GMT+1100 (EST)" I don't really want to do an awkward special-case in FC's source for this one.. this is Safari's fault. If you want to submit a bug to Apple (or whoever?) about this one plz do. Buy yeah, weird. The workaround I mentioned before about turning the timezone setting off will work.
Oct 6, 2014
Hello all, I had the same issue recently for one of my Australian clients. This issue is not specific to MAC Safari. I was able to replicate this on Windows IE browser by taking client's system RD. The main issue is that whenever new date is created in JS using new Date() object then it creates current date time with DST time if applicable. It gives the Timezone in the compete date string. If DST was applicable then it will show "Date time Timezone (Daylight)...." e.g. So in my case I just interpreted that string and if daylight found then subtracted 1 hr. I hope it may help someone.
Oct 8, 2014
This is still happening btw. I got hit by it on the recent changeover. I made a simple test page at http://design9.bz/quickTest.html that prints times and dates around the changeover period. On other browsers the changeover happens at 2am. On iOS+Safari it inexplicably happens at 4pm on Oct 4th.
Aug 21, 2015
Discussion for this issue has moved to the following URL: https://github.com/fullcalendar/fullcalendar/issues/2396 This is because Google Code is shutting down. Apologies if you are being pestered with these notifications. This is a one-time event. Happy coding, Adam
Status:
ExportedToGithub
|
|
| ► Sign in to add a comment |