Date missing UTC getters

[robertjlooby]

There is currently no way to reliably display a given date rather than a localized datetime. For example if I want to say an event is on 1/1/2016, I can use Date.fromString "2016-01-01 which will parse to the datetime "Fri, 01 Jan 2016 00:00:00 GMT". But the only way to get the details out of it (Date.year/month/day) return in the user's locale. Depending on the user's locale this date could be "2016-01-01" or "2015-12-31".

[jvoigtlaender]

Is this maybe addressed by some functionality in http://package.elm-lang.org/packages/rluiten/elm-date-extra/latest/? Even if not, it probably makes more sense to target that package with a feature request than core here (in light of this: https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions).

[jvoigtlaender]

Is this maybe addressed by some functionality in http://package.elm-lang.org/packages/rluiten/elm-date-extra/latest/? Even if not, it probably makes more sense to target that package with a feature request than core here (in light of this: https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions).

[robertjlooby]

It looks like elm-date-extra can format a date in UTC by hacking the date based on timezone, but still doesn't handle the case I'm describing. The functionality could go there first, but it seems like a definite hole in the API that it is impossible to know what Date.day will return for a given Date.Date. Seems like something that is necessary in the Date package, not just a convenience.

[robertjlooby]

It looks like elm-date-extra can format a date in UTC by hacking the date based on timezone, but still doesn't handle the case I'm describing. The functionality could go there first, but it seems like a definite hole in the API that it is impossible to know what Date.day will return for a given Date.Date. Seems like something that is necessary in the Date package, not just a convenience.

[jweir]

See https://github.com/jweir/elm-iso8601 for a date library that is working to solve this problem. This branch is probably the next release https://github.com/jweir/elm-iso8601/tree/dev/return-Result

[jweir]

See https://github.com/jweir/elm-iso8601 for a date library that is working to solve this problem. This branch is probably the next release https://github.com/jweir/elm-iso8601/tree/dev/return-Result

[eeue56]

FWIW the function here needs to be native. It probably needs to be getTimezoneOffset. This is a function that shouldn't/can't be recreated in Elm, as it is a wrapper around an OS's time functions. See here for more reading.

[eeue56]

FWIW the function here needs to be native. It probably needs to be getTimezoneOffset. This is a function that shouldn't/can't be recreated in Elm, as it is a wrapper around an OS's time functions. See here for more reading.

[zweizeichen]

Thank you for bringing this up, IMHO the core Date module is in dire need of this expansion. That by no way means the need for adding expansive timezone support (that would probably be a huge timesink -hehe, I would leave that to 3rd party libs for now). Just some functions for dealing with UTC timestamps (UNIX/ISO8601) would certainly be a nice addition to the core lib as e.g. most backends you'll be getting data from will be using UTC timestamps.

[zweizeichen]

Thank you for bringing this up, IMHO the core Date module is in dire need of this expansion. That by no way means the need for adding expansive timezone support (that would probably be a huge timesink -hehe, I would leave that to 3rd party libs for now). Just some functions for dealing with UTC timestamps (UNIX/ISO8601) would certainly be a nice addition to the core lib as e.g. most backends you'll be getting data from will be using UTC timestamps.

[evancz]

Getting UTC times was first mentioned in elm/compiler#705 and is tracked in #322. Let's track there.

[evancz]

Getting UTC times was first mentioned in elm/compiler#705 and is tracked in #322. Let's track there.