-
-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
October broken on Firefox Nightly #18
Comments
This is a warning I get on the console when I browse to one of the broken Octobers:
|
I am trying to dig into this, the function
|
I wonder if this might be a daylight saving time issue, patching this CalendarUtils.js line https://github.com/gpbl/react-day-picker/blob/master/dist/CalendarUtils.js#L22 to increase the day using:
instead of
fixed the "8 days week" issue (and duplicated day in a week, and duplicate key in react issues), but not the layout of the calendar yet, maybe because of a similar addition or subtractions of day in the code. I will dig deeper and look for a related moments issue as well… |
A simplified testcase: var oct182014Plus1 = moment('2014-10-18').add(1,'d');
console.log('18 of october 2014 + 1 day', oct182014Plus1.format(), oct182014Plus1.valueOf()); On Chrome returns:
and on Firefox:
|
Ok, it boils down to local date vs utc date, one possible fix is to update line #22 of CalendarUtils.js to use UTC instead of local, with:
|
I have created a pull request with a fix, please let me know if this is not the proper fix or the proper way to contribute :) |
@fczuardi thanks for taking care, it is indeed a weird issue. i'd like to investigate it first – maybe a problem with the nightly itself? |
Yes, it might be a firefox bug, please leave an update in the related moment js issue if you figure out. |
@gpbl check the comments on moment/moment#2353 to see the explanation, it is not necessarily a firefox bug since "The ECMAScript spec does not define the behavior for a local time value that falls into a DST transition", just a different implementation. Anyways, from the moment.js folks this issue is a wontfix, they are fine living with october 18 + 1 day = october 18 since in brasilia's local time that day has 25 hours :) As for the react-day-picker side of things, this is still a bug since it breaks the calendar layout. |
Hey @fczuardi thanks for the follow up. Interesting case. Will merge your PR 👍 |
Fix published on npm as v0.8.2 |
Checking on the github commits historty doesn't look like the pr was merged, I will test it later on my computer to let you know if this is still happening in 0.8.2 |
😱 sorry i made all wrong! republishing asap :) |
No worries, thanks for the useful component :) |
v0.8.3 💫 |
@fczuardi I am not yet happy with the fix :-) if we switch to UTC the dates clicked will be passed to the events as UTC as well. Developers doing date comparisons need to be aware about this and always work with UTC dates, which is unfair. For version 1, I'm planning to move away from moment.js (#2): I need to build a small util for date calculations, which eventually should consider this edge case (after all, it happens only in a nightly build, right?). When the test suite is complete we can work better on this. |
For example, if not setting utc() ca7f1a3 this comparison would not work: https://github.com/gpbl/react-day-picker/blob/master/example/src/Utils.js#L15 (not sure why actually 😒) |
I've moved back to the no-utc date, when closing #27 I'll keep an eye on this. |
Should it be fixed with v1 😊 |
Steps to reproduce:
Expected results:
Actual results:
12, 13, 14, 15, 16, 17, 18, 20, 21, 22, 23, 24, 25
The text was updated successfully, but these errors were encountered: