Modifies all dates in the calendar to have their time set to noon #114

majapw · 2016-10-11T22:33:27Z

This is a fix for #110

I also double-checked this change in the Brazilian time zone and noted that there is no reoccurrence of the DST bug that caused there to be an extra day in the month of October. It might be good to double-check Australia as well.

I'm not like incredibly happy about this, but it seems to work. :|

to: @timReynolds @ljharb
FYI: @airbnb/webinfra @wmartins

ljharb

LGTM, but, tests? ༼ つ ◕_◕ ༽つ

majapw · 2016-10-11T22:49:19Z

WAIT I GET IT.

So the general idea is that we were setting the utc offset like so:
month.clone().utcOffset(month.utcOffset());
month is generally set to today's date plus/minus a number of month, courtesy of moment's api. So actually, where this happens (whether it's the Feb/Mar border like in 2018 today or the Mar/Apr border like in 2017 today) depends on which side of the DST day in March we're on). We then set the offset for the entire month based on this initial day and the offset for the entire month after that similarly. As a result, the confusion (one day equaling another due to DST) does not happen on the DST change date itself but on the edge of that month. It also only happens once because the problem only exists when the offset from one day is different from the next. And uh, yeah. THAT'S ALL I'VE GOT.

I am mostly writing this down so that years down the line we'll have a record of this.

majapw · 2016-10-11T22:59:16Z

just kidding, thanks for making me write tests @ljharb. The original code didn't actually do what I expected. :) This should fix things. PTAL!

ljharb · 2016-10-11T22:59:32Z

test/utils/toMomentObject_spec.js

@@ -20,6 +20,10 @@ describe('toMomentObject', () => {
    expect(toMomentObject()).to.equal(null);
  });

+  it('output has time of 12PM', () => {


it might be nice to test the actual conditions - like, that the thing resulting in the extra day being highlighted returns the correct result

This becomes a bit harder to test I think because it... depends on a lot of different factors. I mean, I guess we can check that the first of april/last of march and first of march/last of april do not make isSameDay true but that seems like a bad test?

That would test the actual bug this had reported, and assuming the dates were somewhat hardcoded, would likely prevent a regression. Changing the times to 12:01, for example, shouldn't fail tests, because it wouldn't trigger the underlying bug.

wmartins · 2016-10-12T03:02:28Z

Hey @majapw, I was just fiddling with the code here and I think I've found a simple (and reliable) solution for this problem.

First of all, the utcOffset fix was done to fix the strange behavior of moment#add, that was adding an extra day when there is a timezone change (i.e.: Brazil entering in daylight saving time). The problem is that this utc date is being propagated to more parts of the library, and this is causing the problem, because every other method is now using this "mutated" object (causing the problem with isSameDay as reported by @timReynolds).

So, I think that if you do the reverse process when using the day, you'll be "safe".

In this case, there are just three simple changes.

The first is in prevDay:

// old
const prevDay = enableOutsideDays && currentDay.clone().subtract(i + 1, 'day');
// new
const prevDay = enableOutsideDays && currentDay.clone().subtract(i + 1, 'day').local();

The second is in currentWeek.push

// old
currentWeek.push(currentDay.clone());
// new
currentWeek.push(currentDay.clone().local());

And the third in nextDay:

// old
const nextDay = enableOutsideDays && currentDay.clone().add(count, 'day');
// new
const nextDay = enableOutsideDays && currentDay.clone().add(count, 'day').local();

What do you think about that @majapw?

More about moment#local.
(Updating:) - All tests passed with this solution

majapw · 2016-10-12T15:28:29Z

Does that actually still solve the DST issue @wmartins? I kind of feel like the setting the time to the middle of the day is still a bit safer and a bit simpler.

wmartins · 2016-10-12T15:34:40Z

I would need to test a little bit more to confirm more cases, but if you
think that it is more simple to set the hours, I think it is not a problem.

Just investigated the issue a little bit and brought this alternative
solution. But I think your solution is fine!

Em qua, 12 de out de 2016 12:28, Maja Wichrowska [email protected]
escreveu:

Does that actually still solve the DST issue @wmartins
https://github.com/wmartins? I kind of feel like the setting the time
to the middle of the day is still a bit safer and a bit simpler.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#114 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfQ4Tq_5U3vGsCkaXt5m_VPnQoXOnnAks5qzPyggaJpZM4KULYI
.

majapw · 2016-10-12T17:38:29Z

@ljharb I added some tests that I confirmed used to fail (with the utcOffset) and now pass. Can you PTAL and then we can get this bad boy merged in. :)

ljharb

LGTM! Only nonblocker comments.

ljharb · 2016-10-12T17:56:19Z

test/utils/getCalendarMonthWeeks_spec.js

+  describe('Daylight Savings Time issues', () => {
+    it('last of February does not equal first of March', () => {
+      const february = getCalendarMonthWeeks(today.clone().month(1));
+      const lastWeekOfFebruary = february[february.length - 1].filter(day => !!day);


fwiw .filter(Boolean) works here too :-)

ljharb · 2016-10-12T17:56:53Z

test/utils/getCalendarMonthWeeks_spec.js

+      const lastOfFebruary = lastWeekOfFebruary[lastWeekOfFebruary.length - 1];
+
+      const march = getCalendarMonthWeeks(today.clone().month(2));
+      const firstOfMarch = march[0].filter(day => !!day)[0];


This should probably use .find(Boolean) instead

majapw · 2016-10-12T18:21:46Z

Awesome! I fixed the tests that were breaking as a result of changing the date's time. :) So we should be set now. Will merge in after tests pass.

coveralls · 2016-10-12T18:56:10Z

Coverage remained the same at 87.969% when pulling 1f1c5d0 on maja-change-all-dates-to-have-noon-as-their-time into 73b3ff6 on master.

ljharb requested changes Oct 11, 2016

View reviewed changes

ljharb added the semver-patch: fixes/refactors/etc Anything that's not major or minor. label Oct 11, 2016

majapw force-pushed the maja-change-all-dates-to-have-noon-as-their-time branch from 39b2b92 to 6b8cb0b Compare October 11, 2016 22:58

ljharb reviewed Oct 11, 2016

View reviewed changes

This was referenced Oct 12, 2016

Issue with last day of month after end of Norwegian DST #111

Closed

Range Picker incorrectly highlights 1st April when hovering over an end date of 31st March #110

Closed

majapw force-pushed the maja-change-all-dates-to-have-noon-as-their-time branch 2 times, most recently from 5a24720 to 387e62c Compare October 12, 2016 17:37

ljharb approved these changes Oct 12, 2016

View reviewed changes

Modifies all dates in the calendar to have their time set to noon

1f1c5d0

majapw force-pushed the maja-change-all-dates-to-have-noon-as-their-time branch from 387e62c to 1f1c5d0 Compare October 12, 2016 18:20

ljharb approved these changes Oct 12, 2016

View reviewed changes

majapw merged commit 7b58a2e into master Oct 12, 2016

majapw deleted the maja-change-all-dates-to-have-noon-as-their-time branch October 12, 2016 19:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Modifies all dates in the calendar to have their time set to noon #114

Modifies all dates in the calendar to have their time set to noon #114

majapw commented Oct 11, 2016

ljharb left a comment

majapw commented Oct 11, 2016 •

edited

Loading

majapw commented Oct 11, 2016

ljharb Oct 11, 2016

majapw Oct 11, 2016

ljharb Oct 11, 2016

wmartins commented Oct 12, 2016 •

edited

Loading

majapw commented Oct 12, 2016

wmartins commented Oct 12, 2016

majapw commented Oct 12, 2016

ljharb left a comment

ljharb Oct 12, 2016

ljharb Oct 12, 2016

majapw commented Oct 12, 2016

coveralls commented Oct 12, 2016

Modifies all dates in the calendar to have their time set to noon #114

Modifies all dates in the calendar to have their time set to noon #114

Conversation

majapw commented Oct 11, 2016

ljharb left a comment

Choose a reason for hiding this comment

majapw commented Oct 11, 2016 • edited Loading

majapw commented Oct 11, 2016

ljharb Oct 11, 2016

Choose a reason for hiding this comment

majapw Oct 11, 2016

Choose a reason for hiding this comment

ljharb Oct 11, 2016

Choose a reason for hiding this comment

wmartins commented Oct 12, 2016 • edited Loading

majapw commented Oct 12, 2016

wmartins commented Oct 12, 2016

majapw commented Oct 12, 2016

ljharb left a comment

Choose a reason for hiding this comment

ljharb Oct 12, 2016

Choose a reason for hiding this comment

ljharb Oct 12, 2016

Choose a reason for hiding this comment

majapw commented Oct 12, 2016

coveralls commented Oct 12, 2016

majapw commented Oct 11, 2016 •

edited

Loading

wmartins commented Oct 12, 2016 •

edited

Loading