The time zone "Europe/Amsterdam" is of class TimeZones.Class(:LEGACY)

[rikhuijzer]

I'm unable to run code which refers to tz"Europe/Amsterdam" with TimeZones.jl v1.9.1:

julia> using TimeZones

julia> tz"Europe/Amsterdam"
ERROR: LoadError: ArgumentError: The time zone "Europe/Amsterdam" is of class `TimeZones.Class(:LEGACY)` which is currently not allowed by the mask: `TimeZones.Class(:FIXED) | TimeZones.Class(:STANDARD)`
Stacktrace:
 [1] TimeZone(str::String, mask::TimeZones.Class)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:89
 [2] TimeZone(str::String)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:70
 [3] var"@tz_str"(__source__::LineNumberNode, __module__::Module, str::Any)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:110
in expression starting at REPL[7]:1

This is unexpected since Europe/Amsterdam is a commonly used timezone. The release notes of tz show no mention of the deprecation of the timezone, apart from the following note:

Finish moving to 'backzone' the location-based zones whose
timestamps since 1970 are duplicates; adjust links accordingly.
This change ordinarily affects only pre-1970 timestamps, and with
the new PACKRATLIST option it does not affect any timestamps.
In this round the affected zones are Antarctica/Vostok,
Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik,
Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg,
Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas,
Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion,
Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei,
Pacific/Wake and Pacific/Wallis, and the affected links are
Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape,
Pacific/Truk, and Pacific/Yap.

source: https://github.com/eggert/tz/blob/16ce126a87c5f130cde8b8dce73b38952a19f085/NEWS#L300-L312

And indeed the same error shows up for the zones listed in the note. For example:

julia> tz"Pacific/Ponape"
ERROR: LoadError: ArgumentError: The time zone "Pacific/Ponape" is of class `TimeZones.Class(:LEGACY)` which is currently not allowed by the mask: `TimeZones.Class(:FIXED) | TimeZones.Class(:STANDARD)`
Stacktrace:
 [1] TimeZone(str::String, mask::TimeZones.Class)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:89
 [2] TimeZone(str::String)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:70
 [3] var"@tz_str"(__source__::LineNumberNode, __module__::Module, str::Any)
   @ TimeZones ~/.julia/packages/TimeZones/V28u7/src/types/timezone.jl:110
in expression starting at REPL[14]:1

Is this behavior expected?

[tpgillam]

( The messages on this page were enlightening to me: https://mm.icann.org/pipermail/tz/2022-July/031642.html So if TimeZones.jl wants to mirror IANA, then perhaps this is correct behaviour. )

From looking at the code, it seems that we're not currently looking at the backzone file at all. I've made a minor tweak to the code to include that file as a standard region, after which the Europe/Amsterdam region returns. And this is slightly different to the LEGACY timezone you can get currently, since that's just a pointer to Europe/Brussels now (defined in the backward file).

There is this comment in the file backzone that I could interpret as meaning "where a name appears in both backward & backzone, pick the one in backzone":

This file contains data outside the normal scope of the tz database,
in that its zones do not differ from normal tz zones after 1970.
Links in this file point to zones in this file, superseding links in
the file 'backward'.

[omus]

Sorry about this disruptive change. Typically the tzdata updates are rather minor but this latest one changed more than I realized. I'll try to add some tests to catch these more major changes and possibly tag these changes as a major release (need to give this a little more thought). Alternatively, we may want to add support for properly deprecating these kinds of class changes so that Julia code doesn't break with tzdata changes.

You can still construct these time zones using TimeZone("Europe/Amsterdam", TimeZones.Class(:LEGACY)) as a work around for now.

From looking at the code, it seems that we're not currently looking at the backzone file at all

The backzone file is a new addition and we'll need to determine if it should be incorporated as a standard time zone or kept as legacy.

[yakir12]

Is there any functional difference between TimeZone("Europe/Stockholm", TimeZones.Class(:LEGACY))
and TimeZone("CET")...? It's just easier for me to solve this by swapping "Europe/Stockholm" with "CET"...

[omus]

Is there any functional difference between TimeZone("Europe/Stockholm", TimeZones.Class(:LEGACY)) and TimeZone("CET")...? It's just easier for me to solve this by swapping "Europe/Stockholm" with "CET"...

Historically there is a different between those two:

julia> TimeZone("CET").transitions == TimeZone("Europe/Stockholm", TimeZones.Class(:LEGACY)).transitions
false

I would recommend using "Europe/Berlin" as the replacement for "Europe/Stockholm":

julia> TimeZone("Europe/Berlin").transitions == TimeZone("Europe/Stockholm", TimeZones.Class(:LEGACY)).transitions
true

As general advice if a time zone has been deprecated (marked as legacy) I recommend you use the alternate name for that time zone which can be found in the backward tzfile: https://data.iana.org/time-zones/tzdb-$(release)/backward (e.g. https://data.iana.org/time-zones/tzdb-2022f/backward).

I'll make a new issue about providing this information automatically to end-users (via the exception) if the time zone they are using has been deprecated.