jtsage / jtsage-datebox

A multi-mode date and time picker for Bootstrap (3&4), jQueryMobile, Foundation, Bulma, FomanticUI, and UIKit (or others)
http://datebox.jtsage.dev/
Other
474 stars 166 forks source link

Calbox with blackDays = [1,2,3,4,5,6] breaks in October on Safari and Mobile Safari #370

Closed chrisjrn closed 9 years ago

chrisjrn commented 9 years ago

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.

2015-03-04 at 10 22 am 2015-03-04 at 10 22 am 2015-03-04 at 10 22 am

jtsage commented 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)

chrisjrn commented 9 years ago

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.

jtsage commented 9 years ago

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

chrisjrn commented 9 years ago

Using a constructor for midday should make the issue go away entirely (given that DST swaps at 2-3AM every day.

jtsage commented 9 years ago

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:

chrisjrn commented 9 years ago

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 :)

jtsage commented 9 years ago

Thanks. I should have a few free hours tomorrow to give an attempt at this.

jtsage commented 9 years ago

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)