The problem with timezones

The problem:

1. A user selects a date with ember-power-calendar. Let’s say it was: Sat Oct 20 2018.
2. The addon returns as a date field native JS Date object with the user’s browser timezone. In my case, it is: Sat Oct 20 2018 00:00:00 GMT+0100 (British Summer Time).
3. Since Date object is nicely consumable by ember-data the developer might easily pass that value directly to some model property.
4. Once ember-data tries to save that property (typically through json-api serializer), here’s what gets passed to the server: 2018-10-19T23:00:00.000Z.
5. Then if the server stores only DATE, without the time part it might happen that the wrong date gets saved. That is actually how I bumped into this bug.

See the one hour difference that leads to a different date. That is because there is different timezone.

I kidna do understand that the information is still there and I can recalculate the “correct selected date” using the information about user’s timezone. But I feel like the consumer of this addon should not care about this. If the addon always returns date in UTC, then there should be no problem. Something like:

new Date(Date.UTC(2018, 10, 20));
Tue Nov 20 2018 00:00:00 GMT+0000 (Greenwich Mean Time)

I tried to isolate a minimum reproducible code here.

Thanks for consideration.

[fran-worley]

For me it would be useful is if you could configure the datepicker for moment to be in utc mode (and for dates, it might be sensible to turn this on by default).

It’s such a pain that for half the year all my dates are out by 1 day unless I override the getting/ setting of moment.

[jonnygreen]

On reflection, my comment above is not a good solution as timezones that are behind UTC would end up with a date object that if interpreted as local time, would be a day early. So big backwards compatibility issues. Whoops 🤦.

It needs something though - I think @fran-worley’s approach of being able to configure PowerCalendar in UTC mode is a good one. In the meantime, we’re implementing a wrapper that massages the date object to produce the date we expect in UTC.