Date Selected is One Day Off

[YOO629]

Hi, I'm having an interesting issue with my usage of the datepicker component.

My code is pretty basic, it looks like this:

<ReactDatePicker
  onChange={(val) => this.handleChange(val)}
  selected={this.state.currentDate}
/>

and my handler fn

  handleChange(momentDate) {
    console.log(momentDate.toISOString())
    this.setState({currentDate: momentDate});
  }

The issue that I see is that when I select a date from the dropdown, the visual aspects of the component appear to be working fine -- I select 09/10 (sept 10th) and that's what I see in the input field.

However, in my console.log() in my handler function, I see that when I select 09/10, the output is 2017-09-09T21:00:00.000Z. momentDate.toISOString() is ultimately what I'm sending to the DB to be saved, so it's problematic that it's one day off.

I'm not sure what to make of this. I was expecting to see 2017-09-10T21:00:00.000Z. It looks like
momentDate is localized, so if I'm in a UTC + 3 timezone and choose 09/10 00:00:00, I'm actually choosing 09/09 21:00:00 (my hypothesis). Even if I set the utcOffset prop to 0 it looks like the localization is still happening.

Am I doing something wrong? Is there a way for me to just kind of...turn off the localization? I'm using the component purely to just pick a day in the calendar. I don't care what timezone they're in, if they pick 09/10, they pick 09/10.

Thanks!

[nwkeeley]

Also experiencing this issue.

I open it up, select date its off by 1 day. I then open it up and select any other subsequent day and its correct.

[xarxziux]

I've run into this problem too. This seems to appear in release 0.44.0. From my tests, 0.43.0 behaves correctly and reports the date selected. Release 0.44.0 reports the day prior to the day selected.

From reading through the commits, it's likely that the problem is somewhere in commit a95cd86, but I've not been able to identify the exact cause.

[xarxziux]

Scrap that last comment. Release 0.43.0 worked fine on a test project, but it's now showing the same error on my main project. The hunt continues...

[xarxziux]

From further tests, I can actually turn this bug on in a test project using release 0.41.0 just by setting the startDate to null in the constructor function. Setting it to moment() turns the bug off again.

Release 0.40.0 doesn't seem to have this problem.

[romanveryovkin]

The same issue for me as well. Do anybody have some workarounds?

[RobMaple]

I've just run into a similar sounding issue to this although on closer inspection it seems to be relating to when daylight's savings time ends at the end of October. Selecting a date after this point initially causes the date picker to be one day behind, selecting a date a second time seems to fix this. The 'fix' seems to relate to the moment object having no utc offset the second time - why this is though I'm not sure.

To get around this i'm currently setting the 'utcOffset' prop on the datpicker component to 0 -- this prevents the initial selection from shaowing as the day previous. I'm wondering if this is actually a bug with react-datepicker though or more to do with how dates are handled and manipulated within my app.

[aij]

@RobMaple Are you able to reproduce it with the examples at https://hacker0x01.github.io/react-datepicker/ ?

DST ends on Nov 5 for me, but selecting days before and after seems to be working. (I tried clearing and not clearing at various points, but it didn't seem to make a difference.)

[RobMaple]

@aij The example worked fine although when I updated the version of react-datepicker to 0.55 (the same as in my project) the issue returned. Just updated it to 0.56 however and all looks to be working correctly again 😀

[aniruddhashevle]

This issue is there in v0.58!

[mwickett]

We're seeing this issue on 0.61 as well. With some testing, it looks like it only happens in a GMT negative timezone (WEST of GMT). Setting my machine's timezone to a positive value returns a proper date.

Setting the utcOffset prop to 0 doesn't change anything.

[swellmar]

@mwickett @RobMaple Where do you find this utcOffset prob? I can find it on 100 different places

[tastypackets]

Using v0.39 it corrects after selecting a second date. For example select 12/20/17 and it will be 12/19/17, then select 12/22/17 and it will be 12/22/17.

Initializing it with a date like @xarxziux mentioned does work.

Edit:

I just undated to v0.64 and it is now working properly even with defaulting to null.

[guyzmo]

I'm having that exact same bug, and I just understood what's wrong after chasing my own tail for hours. As I'm only interested in dates, in the date selector, the handled value is a Date object with a time set to midnight.

As the selection of the date is in current local time (I'm in CET time), and the storage is in UTC, local time gets shifted by one hour backward when stored. That makes selection of 2018-02-20 with a default to midnight getting stored as 2018-02-19T23:00:00.000Z.

And because in my code I was doing a Q&D conversion from Datetime to string by splitting over T, I was setting the value back to the wrong date.

Solution, in my case? use momentsjs e-ve-ry-whe-re!

[azza85]

I had the same issue,, with the date selected going back a day. I fixed the issue for me by adding

selected={null}

The reason I had it blank was if I had it set as

moment()

it was displaying today rather than my placeholder text