Closed chrisjrn closed 9 years ago
This is incredibly odd. And I totally confirmed this when you sent it.
Today however... I fixed it?? (no idea, can you give it another shot on your end?)
(tested mac+chrome&safari, iphone)
We did investigate the issue on our end -- what causes the issue is
that the default Date(
constructor on Safari defaults to midnight;
however, the changeover date for Daylight Saving Time will return
23:00 on the day before in Safari.
I expect you'll see similar behaviour in early March for Northern Hemisphere timezones.
I'll take a look over here shortly.
Ah. Ya know, up to this point, DST hadn't bit me on any of the date modes, just time. But this absolutely makes sense - thanks for digging deeper
I'll try and get a fix in there
Using a constructor for midday should make the issue go away entirely (given that DST swaps at 2-3AM every day.
Except, that i've just read that's not always true - there are a few places in the world it happens at midnight (one of which, if the web page I was just on is right, is Iran - who knew... also, until recent history, Brazil appears to have changed the clocks whenever they felt like it)- also screwing with the date in the process I'd suspect. A best fix would be to follow UTC throughout, but support for that is incredibly spotty. Midday will probably be the best option, I just need to look at how I am generating dates - it's been a while since I've been in that block of code, but I believe I deliberately pass all zeros to the non-significant parts of the date (midnight and zero milliseconds as it were).
For my own reference, what timezone / locale are you in, as that should make reproducing this a lot easier on my end (bonus points for being in one of the cool places in the world that does a +/- 30 for DST too - I know it exists, and I haven't the foggiest idea what that might break)
Note: the fun references:
On 14 August 2015 at 10:56, J.T. Sage notifications@github.com wrote:
For my own reference, what timezone / locale are you in, as that should make reproducing this a lot easier on my end (bonus points for being in one of the cool places in the world that does a +/- 30 for DST too - I know it exists, and I haven't the foggiest idea what that might break)
I'm in Australia/Hobart, which is one of the less interesting places, sorry :)
Thanks. I should have a few free hours tomorrow to give an attempt at this.
Just gave a shot at this. Tiny fix, but I can no longer reproduce. (And by setting the same timezone as you, and firing up safari, I was able to reproduce the original bug)
We have a calbox set up with the following configuration:
{ "mode":"calbox", "useFocus" : true, "blackDays" : [1,2,3,4,5,6], "overrideCalStartDay" : 1 }
With this configuration, in Safari 8.0.3 on Mac OS X 10.10, and also in Safari on iOS, the first Sunday in October of any given year is not selectable. (See screenshots)
No other months are affected.
No other browsers appear to be affected.