I'm experiencing weird issues with the DateTime field type when used in different timezone conditions.
Although the time is correctly stored in UTC, it gets converted into local time in the Admin UI. It then gets interpreted as UTC and 'shifts' when you save.
High priority bug, I'm going to look into it asap. If anyone else has experienced it or can help, that would be appreciated.
Check out PR #1445
Adding utc option to Date and DateTime fields, fixes #1487
Thanks for the pointer @WingedToaster, I'll update that PR with some notes shortly.
After some research, it appears that date fields don't play nicely if the server and browser are in different timezones, and dates are inserted into the database with explicit timezone information (in my case it was UTC) in the initial value.
To work with this (for now) I've added a utc option to the Date and DateTime fields, which enable moment's utc mode when parsing input and getting date values, on both the client and server.
If you simply use Keystone's Admin UI to set date values, or accept them (e.g from an import script or form) without timezone information you won't experience this problem.
e.g "2015-07-03 10:00:00"
At this stage, to support timezone-enabled date values, the safest way is to store and edit UTC (using this new option) then convert them with the correct offset for display. This isn't ideal, and I'll review #1445 and land a more comprehensive timezone solution in the future.
Thanks @JedWatson this was driving me nuts!
Hi we've got this problem as well.
We have a model with a date time. It's correctly saved as UTC.
When displaying the datetime in a list view, the time renders correctly however in detail view (edit) of the object, the time is shifted 1h (I don't have access to the server but I'm pretty sure it's the server time).