Keystone-classic: Saving causes published date to rollback 1 day

[jimulle]

Every time I save in the Admin UI, the published date for the item I just saved rolls back one day (regardless of editing the published date field)

Saving with date '2015-04-22' inputs '2015-04-21' in the database (and subsequently displays that new date when the page reloads).

[matthewchung74]

seems to work fine for me. i'm on version version 0.3.14.

[mxstbr]

I'll close this since it's not reproducable, if this issue still exists for you feel free to comment again!

[kraigh]

I have this exact issue on 0.3.19. Any ideas what could be causing it? Tested on Firefox and Chrome on OSX.

[wmertens]

Could it be that the browser and the server are in different time zones?

[kraigh]

Yes, the server is UTC and my browser is CST. How can I fix this?

[wmertens]

Then this is a bug in Keystone. Dates should be handled in UTC.

[wmertens]

It looks like it should be sufficient to use the moment.utc(…) functions in https://github.com/keystonejs/keystone/blob/master/fields/components/DateInput.js

[wmertens]

Basically, dates without time should be formatted and parsed in UTC, so they don't jump depending on time zone. Not sure how far that impacts things, and it will probably break existing deployed code that assumes that the date value it gets from the server is in the browser time zone.

Let's fix this and make sure people realize it's a breaking change.

Alternatives:

• store date-without-time values as the string YYYY-MM-DD. This doesn't break lexicographic sort, easily converts to a Date value, takes less room in JSON, and makes it explicit that there is no time zone attached to it. May break even more code assuming to get Date objects, may cause lots of back-and-forth conversions
• store dates as noon on the +12 timezone, so that no matter what time zone it gets converted to, it still is the same date. This may cause the least breakage?
  
  
  
  • (My math may be off here, I mean the moment in time that is in the same day for all time zones. It may not exist, be off by a second, so that may also be a problem)
  
  

Anybody experienced at reliably storing dates?

[arthurcamara1]

Same happening here. :(

[wcalebgray]

+1 same issue happening here

[jstockwin]

@wmertens This is also an issue for Datetime, and your second alternative won't fix that, so not that one. I think I agree with your initial suggestion of storing in UTC. A breaking change to fix a bug is okay...

This issue is also holding back proper e2e testing, since the travis servers are in a different timezone to saucelabs, or something like that.

[kraigh]

I agree that storing dates as UTC is probably the best solution.

Would adding a sitewide "timezone" setting so keystone knows what to convert the dates/times to when displaying be helpful in this case?

[eastenluis]

Working with v0.3.22. Still see this bug. I have to reset the date input(s) every time I save a post. If I forgot to do so, the rolled-back day will be stored in the second and next saves and hence keep decreasing as I save.

[waltonryan]

Anybody find a fix for this? Maybe a way to add a pre save hook? I'm getting the issue on "keystone": "^0.3.16".

[internetErik]

I had this issue with 0.3.22 and then upgraded to 0.4 beta 4 and the issue still persists. (In 0.3.22 it also happened with the datetime field, but this seems fixed now.)

The doesn't present itself in my local development environment (presumably because the timezone is the same on the system and the browser). However, when running in AWS the issue presents itself because of the timezone difference (people have already noted this).

If there any fix or workaround for this in the works?

[Noviny]

Hi all,

Trying to solve for this, as it's one of the things holding up Keystone4 getting out of beta.

I just wanted to check that this is not an issue for datetime, which I haven't been able to reproduce it with, though I can consistently reproduce it for date.

[CameronSima]

I'm having the same issue, and my server and browser are in the same timezone. Anyone come up with a decent workaround?

[Noviny]

@waltonryan Unfortunately the problem occurs in the data the admin UI sends back, so it needs to be resolved around there.

@CameronSima Current workarounds are:

• Set the server is in same timezone as the the end users
• Items with a date field are not saved through the admin UI

[CameronSima]

@Noviny Thank you. What's confusing is that my server and end users are in the same timezone

[Noviny]

@CameronSima Sorry for not reading your initial message closely enough.

Are you capable of confirming that? Running new Date() on the server then locally should give us the information.

I'd also like to see what the data looks like, so if you could grab one of the ISOStrings that would be great.

[CameronSima]

@Noviny Output of new Date() on server: Wed Mar 08 2017 00:20:16 GMT+0000 (UTC)
and on my local machine: 2017-03-08T00:20:27.146Z

[CameronSima]

@Noviny hope that helps, let me know if I can supply any other information

[intmainvoid]

I’ve done some testing around this and discovered the following issues:

1/ If using a field with type “Date” (ie. Types.Date) in the model without the UTC option turned on AND the keystone users are in different timezone(s) to where the server is running, dates may be recorded inaccurately. Specifically, when the user clicks on the save button for a form that contains a date, the date saved (and subsequently displayed) may be the date for one day before the date intended to be saved.

2/ If using a field with type “Date” (ie. Types.Date) in the model with the UTC option turned on, the incorrect date may be displayed upon selecting a new date from the date picker. Specifically, whenever the user selects a new date, the date for the day immediately before that date would be displayed. Clicking on save at that point would cause that incorrect date to be saved. This happens irrespective of the configured timezone(s).

I’ve built (together with @export-mike) what hopefully amounts to a fix for these two issues. See linked PR: https://github.com/keystonejs/keystone/pull/4112

[Noviny]

Closing this as resolved, as #4112 has been merged. This will be fixed in keystone versions after v4.0.0-beta5