elm-datepicker icon indicating copy to clipboard operation
elm-datepicker copied to clipboard

date selection should be UTC

Open trippingtarballs opened this issue 6 years ago • 1 comments

Issue

When a date is selected from the elm-datepicker the Date is of a local-time format. As a consequence, when the chosen Date is serialised, an incorrect value is sent over the wire.

> (new Date('2018/06/01')).toUTCString()
"Thu, 31 May 2018 23:00:00 GMT"

The time portion of the chosen Date is defaulting to midnight. And, after a correction for British Summer Time is applied, the serialised date is set to 23:00 of the previous day. 😢

Solution Presented

This PR changes the implementation of the mkDate function in the DatePicker.Date module. Using a - separator (instead of a /) means the Date.fromString function will produce a UTC formatted date, as illustrated here:

> (new Date('2018-06-01')).toUTCString()
"Fri, 01 Jun 2018 00:00:00 GMT"

In this way, when the datePicker view-function (of the DatePicker module) constructs its table of dates, the Pick message-constructor (bound to the onClick handler) will be applied to a UTC formatted Maybe Date.

Solution Alternative

Perhaps it would make more sense if the parser property of the Settings record were to be used in the unsafeDate function (called by mkDate in DatePicker.Date module). After reading through the project's Issues I believe the the parser option was added to support custom date formatters (https://github.com/elm-community/elm-datepicker/issues/15). But the parser is only used by SubmitText message (which is triggered when a date is entered manually).

trippingtarballs avatar May 03 '18 15:05 trippingtarballs

Thanks for the PR and apologies for the delay. Timezones are always a difficult topic! This might be a tricky change to make, since it'll require a warning to existing dependents that the library is going to change its parsing process, particularly since it doesn't change the type signature and won't stand out in an upgrade. Weirder, someone could argue that it's correct for a user's idea of "June 1st" to correspond to "late May 31st UTC", depending on context. Does that seem like a reasonable concern?

Is it feasible to correct for timezone offset outside of the picker? Something like this dashed-off JS, cleaned up and/or in Elm?

const offset = date.getTimezoneOffset()
const utced = new Date(date.valueOf() + offset * 60000)

bbqbaron avatar May 28 '18 16:05 bbqbaron