5

I want to get a Date in elm that represents the user's local date and time. I have looked at the core Date module as well as the elm-time package.

The elm-time package has a ZonedDateTime, but a TimeZone value must be supplied to it, and therefore, the time zone must be known ahead of time.

At its core, this issue is about reliably determining the user's timezone. The best solution I've come up with, which is too naive to be considered acceptable, is to pass the user's timezone offset via javascript as an application flag and modify a UTC date accordingly.

w.brian
  • 16,296
  • 14
  • 69
  • 118

3 Answers3

1

With the current 0.19.1 version:

  • Use Time.here : Task x Zone to get the current time zone.
  • Use Time.now : Task x Posix to get the current date.
adauguet
  • 988
  • 8
  • 18
0

It seems like the Date.now task will return the timezone information in the resulting Date. However, I didn't find any actual Date api functions which actually allow access.

Once you have the Date, though, I was able to use the getTimezoneOffset function from the rluiten/elm-date-extra package to ge tthe offset in raw minutes. You could try to deduce a timezone from that offset.

Alternatively, you could toString the Date returned and parse it out of that. It ends up as a string like this: <Tue Jul 17 2018 23:45:19 GMT-0700 (PDT)>.

kjw0188
  • 3,625
  • 16
  • 28
  • 1
    It's not possible to reliably deduce a timezone from an offset, because a timezone is inherently tied to a particular country and the dates it has chosen for starting and ending Daylight Savings Time. For example, you might see the time offset GMT-0500 because you're in the United States' Eastern time zone and it's winter so Eastern Standard Time is in effect, or you're in the United States' Central time zone and it's summer so Central Daylight Time is in effect, or you're in Columbia which does not observe DST so the time offset is UTC-5 year round. – rmunn Jul 19 '18 at 09:37
  • This will matter if you're doing date calculations; for example, if you ask "What time of day was it 24 hours ago?", the answer you'll get is *usually* going to be "the same as now". But if your time zone just went through a "spring forward" or "fall back" daylight-savings-time transition, then the answer might be "It's 13:45 right now, but 24 hours ago it was 12:45 (or 14:45)". Unless your app is being used in Columbia, which doesn't do those transitions. So knowing the right timezone can matter for certain apps, and it's not possible to know that *for certain* from an offset alone. – rmunn Jul 19 '18 at 09:39
  • 1
    Also if you're tempted to use IP geolocation to determine timezone: don't. That's not reliable either. Lots of people use VPNs for all kinds of reasons; if your Columbia-based user is using a VPN to access his company network in America, and uses your Elm app while still signed in to his America-based VPN, you'll calculate an incorrect time zone for him, and your app will produce incorrect results every 2nd Sunday in March and 1st Sunday in November. (Or at different dates than that if the U.S. Congress decides to change those dates again.) So IP geolocation isn't reliable for time zones. – rmunn Jul 19 '18 at 09:43
  • These points are true. This is the best Elm language answer I was able to find at the time of writing. I think if you really want to know the user's timezone, the app needs to ask them for it. – kjw0188 Jul 20 '18 at 21:51
0

The Intl API provides a way to get the user's current timezone:

Intl.DateTimeFormat().resolvedOptions().timeZone

It returns either an IANA string like "Australia/Sydney", or undefined.

Browser support seems strong among modern browsers, according to kangax's compatibility table.

Robert K. Bell
  • 9,350
  • 2
  • 35
  • 50