React-datepicker: Timezone mishandling / confusing interpretations.

[aij]

Sorry if I'm misunderstanding something obvious. I would really prefer not to have to think about timezones and timestamps when using a date picker. In that regard I agree with #498.

I think the confusion stems from the fact that moment objects do have a time and utcOffset in addition to a date and that different contributors have different ideas over how said objects should be interpreted.

As an example, the "Specific date range" sample code appears to make the assumption that the date part of the moment object determines the date being specified. (And hence that the time and utcOffset are ignored/unimportant.)

A seemingly conflicting example is #747, which seems to imply that the the date associated with the moment object should be ignored, and instead only the instant in time to which the moment object refers is what should be taken into account.

I think a lot of my confusion is due to changes between versions 0.39, 0.40, and 0.41. Version 0.39 did comparisons using UTC dates by default. (Which is what I coded for originally.) Version 0.40 changed to default to a fixed offset from UTC instead. (In both cases, onChange would sometimes produce local moments, resulting in inconsistent interpretations of minDate/maxDate when such dates were fed back in via selected.) In version 0.41.0, the introduction of preSelection in #673 seems to have changed things to local moments by default.

If I understand correctly, the behavior should now be generally unsurprising as long as only local moments are passed in. (If you expect the moment to be interpreted as it's associated date.) The only exceptions I see (as of 90d3fea) are if the today button is enabled or if the calendar component is used directly without specifying a preSelection or selected moment.

Would it make sense to have those default to using local moments too? (Eg: Clicking today could produce a local moment, with the date that is current at utcOffset, that way passing the moment back in via selected will not change the interpretation of other props.)

If not, could someone explain/document how things are expected to work instead, so that we can make everything consistent?

[jcrben]

If we don't care about the time, an option to use UTC all the way through - with an initial adjustment to get it back to the local time to avoid crossing over to the next day - could make sense since toISOString() always returns a UTC datetime. So we avoid the chance of someone accidentally calling toUTCString() on a local time, which can cross over to the next day. That's what I'm dealing with right now.

I addressed the problem in my case with a utcOffset(0) call to zero it out before calling toISOString. This is inside a reusable component so it just gets called in that one spot.

[Aprillion]

I was able to do startDate.toISOString().substr(0, 10) with <DatePicker utcOffset={0} ... which ~works just fine for me locally in UTC+2 time zone (not using moment at all)...~

~Not sure I understand the problem here, did I miss something and should be worried?~

edit: nevermind, it's totally fucked up - works only when I select the date from chooser, it is 1 day off when I type a date manually and remains 1 day off when I select a date afterwards 😢

[xizi-xu]

I believe that if you use the picker, the picked time value is in GMT/UTC. However, if the time value is typed, it will be in local time zone. Also, it seems that setting utcOffset value does not anything.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.