Add support for deprecated timezones

[cjmeeks]

I was wondering if you were open to adding support for deprecated timezone such as "US/Arizona", "US/***". My reasoning behind this is that T work in the healthcare industry and a lot of hospitals are well behind the times in technology and still use the deprecated timezones. I would also assume that when interfacing with an older server would result in the same sort of incompatibility.

Currently my fix is to just map the old timezone to the new time zone. But it would be better if this package just handled all timezones.

[justinmimbs]

Oh my, that is behind; I see that US/Arizona was deprecated in 1993.

I'm curious: where are you getting the old zone names from at run-time? And are you wanting to be able to look up zones in the zones dictionary by the old names?

For your current fix, how many old zone names are you mapping? Does the backward file (linked above) contain all the mappings you would need?

I hope you don't mind all the questions; I'm very curious about your use case.

Thanks!

Justin

[cjmeeks]

Yeah super behind. Currently I am getting these zones from an EMR at a hospital.
Yes I would like to lookup in the dictionary with those names.
My current fix is this
`mapDeprecatedTimeZones : String -> String
mapDeprecatedTimeZones str =
case str of
"US/Alaska" ->
"America/Anchorage"

    "US/Aleutian" ->
        "America/Adak"

    "US/Arizona" ->
        "America/Phoenix"

    "US/Central" ->
        "America/Chicago"

    "US/Eastern" ->
        "America/New_York"

    "US/East-Indiana" ->
        "America/Indiana/Indianapolis"

    "US/Hawaii" ->
        "Pacific/Honolulu"

    "US/Indiana-Starke" ->
        "America/Indiana/Knox"

    "US/Michigan" ->
        "America/Detroit"

    "US/Mountain" ->
        "America/Denver"

    "US/Pacific" ->
        "America/Los_Angeles"

    "US/Pacific-New" ->
        "America/Los_Angeles"

    _ ->
        ""`

The backward file looks like it has everything that would be needed.
Although having this package be updated with these deprecated zone names would be nice I have other solutions available to me.
Was just curious what your thoughts were.

[justinmimbs]

Interesting, thanks!

I'm thinking that this package could add another dict, perhaps called TimeZone.Backward.zones or similar, which would include the old and new zone names. A user would only need to use one of the zone dicts, and keeping them separate would avoid the extra bloat for the common case (it looks like the old zone names are about 2 KB worth of string data).

What are your thoughts?

[cjmeeks]

I think that is a great solution!

[justinmimbs]

Right on! I'll leave this open until I can implement such a change. Thanks again for helping me understand your use case.

[cmditch]

Will this handle "aliased" names as well? I just ran into this with the "UTC" zone name on Google Calendar's API.

Looks like there are a lot of aliases here. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
(UTC, UCT, etc).

[justinmimbs]

Hi Coury,

This package already includes current aliases (e.g. Africa/Addis_Ababa aliases Africa/Nairobi). However, the package does not include the Etc zones (those are static offsets like Etc/UTC and Etc/GMT+5).

It looks like UTC and UCT are backward-compatible (deprecated) aliases for Etc/UTC, so in order for this package to support looking up, for example, the zone name UCT, it would need to not only support backward aliases but also include the Etc zones.

That's interesting you received UTC as a time zone identifier name, as it would be in both uncommon cases. By chance, was the full name Etc/UTC? Or do you think it was meant to be an offset abbreviation, like PST or EDT, rather than a zone name?

Thanks,

Justin

[cmditch]

Hopefully this answers your questions.

Raw Google Calendar data:

Google Calendar API - Event:
https://developers.google.com/calendar/v3/reference/events#start.timeZone

Google Calendar UI for adjusting timezone

[justinmimbs]

The docs say start.timeZone should be an IANA time zone name. But if this API commonly uses the string "UTC" there, then that sounds like a quirk, and a condition you could safely check for.

In your example case dateTime already includes the offset--can you simply ignore timeZone when the offset is present?

[cmditch]

Yeah, it's no problem to append TimeZone.zones with whatever zones I might need tbh.

ianaTimezones : Dict String (() -> Zone)
ianaTimezones =
    TimeZone.zones |> Dict.insert "UTC" (\() -> Time.utc)

I really only make use of the timezone in a GCal.Event for generating recurring events, as the offset won't take into account DST changes.

[erlandsona]

Just ran into this exact same issue. Apparently Microsoft & Google use the same shape for start/end dates cause I ran into exactly this trying to render Graph API response data to a TUI calendar via web components.

#4 (comment) Thanks for this!

[erlandsona]

Turns out this lib also seems to be missing the concept of "links"?

We have a Ukranian team who discovered an issue with our Calendar implementation that seemed to be missing the "Europe/Kiev" link.

I can vendor this lib in and add just that one but I'm curious if there's a more thorough approach to ensuring the "links" are all included?

[justinmimbs]

Thanks @erlandsona. This library does support links, but the link from Kiev to Kyiv is in the backward compatibility section of the tz database. This library doesn't currently include any of the deprecated zone names, which is indeed what this issue is about.

[k-bx]

For now, I've made a fork accounting for Europe/Kiev and Europe/Zaporozhye. Might add more as I encounter.

Package: https://package.elm-lang.org/packages/k-bx/timezone-data/1.0.0/
GH: https://github.com/k-bx/timezone-data