Improper handling of daylight saving time in *month* view

[okcompute]

Hi,

We found an issue with daylight saving time. Event are shown one day before their real dates for the week where daylight saving time gets effective.

Probably the rendering is relative to the first day of the weeks which is in eastern time.

We will try to look more into on our side.

Thanks!

[vinceprofeta]

I am also experiencing this. +1

@okcompute were you able to find a solution?

[vinceprofeta]

@intljusticemission Any update on this?

[jquense]

there is not, hopefully get some time soon to look into it, but if you want to PR something i'd gladly take it. :)

[MattWilliamsDev]

+1 on this one also. Have been bending over backwards trying to figure this out, but nothing so far.

[MattWilliamsDev]

This could be relevant:
http://stackoverflow.com/questions/21318357/moment-js-issue-adding-days-with-daylight-savings-time

This does boil down to a V8 bug though, so it could still be related to this.

[jquense]

Is this only relevant with the Moment localizer? It doesn't seem to affect globalize (which is what we use) buy I may also just be missing the bug...

[MattWilliamsDev]

I'm unsure, as I have only used the moment localizer. I can assure you though, that for events of the week that DST begins (or ends, I assume), all of the events after Sunday (which is non-DST at midnight) are pushed forward one day, so the event you get in the function passed to props.onSelectEvent actually has a date from the next day.

[shaynethiessen]

Yeah, I'm having this same issue and am also using Moment.js. Has anyone found a solution?

[MattWilliamsDev]

Sadly, no - unless you want to try your hand at manually checking if the start of the week is/isn't DST and the end of the week is different.

If that is the case, then you know that the events after the start of DST at 2 or 3 am on the day that DST changes will be off by one day until the next week. At that point, you could then possibly switch the dates to use 12:00:00 (noon) instead of 00:00:00 (midnight), which should alleviate the issue of the dates being recognized as the day before.

That said, timezones and DST implementations are a pretty unpredictable game to play, as it gets down deep into all sorts of issues related to who implements DST and who doesn't, and if they do, when do they implement it. It is quite a mess.

I have tried to think of quicker solutions to it, but it isn't imperative to our use case, so we instead opted to make the event seem unclickable. The date itself is clickable, and in our case, triggers the showing of a list of all of the events for the selected day beneath the calendar itself. That might not really help you, but hey, maybe it does.

[jquense]

[...] timezones and DST implementations are a pretty unpredictable game to play, as it gets down deep into all sorts of issues related to who implements DST and who doesn't, and if they do, when do they implement it. It is quite a mess.

This is exactly why we delegate to Moment or Globalize, because they have a better chance of getting it right then us :P. I do want to make sure tho that this is a bug in moment and not the Calendar, I'm sorry I haven't gotten a chance yet to dig in (rl is very hectic now).

[MattWilliamsDev]

Completely understood, and if I had the time (and the team had the available resources), I would attempt to narrow the issue down to the moment localizer myself. For now, we just went with a workaround, but I find it likely that it is an issue with (at least) moment itself, and possibly even related to the known V8 bug that I referenced towards the top of the thread.

I feel like I had a reason that I didn't think calculating everything from noon instead of midnight (as described in my last comment) was the right solution/workaround, but now I can't remember what it was. Do you foresee an issue with doing that when the eventSegments are calculated?