Support for backwards compatible time zone aliases

[straight-shoota]

The zoneinfo database typically uses symlinks to connect locations with identical content but different names. This works implicitly with Time::Location.load.

There is a distinction though between current aliases and legacy aliases which are only kept for backwards compatibility.
Some packages no longer keep the latter as symlinks on the file system. For example, the tzdata package in debian removed backward compatibility aliases in version 2023d-1 (https://salsa.debian.org/glibc-team/tzdata/-/blob/6bce3482cda5148d16a4d013a2cf3bfa18de7b74/debian/NEWS#L23-35).

As a result, these symlinks no longer exist and Crystal's time zone loader cannot find them.

For example, the symlink for America/Buenos_Aires is missing in debian testing (trixie) with only the tzdata package installed, while it exists in debian 12:

debian:stable$ ls -ld /usr/share/zoneinfo/America/Buenos_Aires
lrwxrwxrwx 1 root root 22 Mar 26 20:52 /usr/share/zoneinfo/America/Buenos_Aires -> Argentina/Buenos_Aires
debian:testing$ ls -ld /usr/share/zoneinfo/America/Buenos_Aires
ls: cannot access '/usr/share/zoneinfo/America/Buenos_Aires': No such file or directory

We use this name in specs and examples. Apparently it's a legacy name and the actual name is America/Argentina/Buenos_Aires which honestly feels like a quirk, but that's what we got 🤷 We should probably change the references to the current name instead.

It's possible to regain these symlinks by installing the tzdata-legacy package. But requiring that does not seem like a reasonable solution.

We should make Crystal's time zone loader aware of backwards compatibility aliases even when symlinks do not exist.

Backwards compatibility aliases are statically available in https://data.iana.org/time-zones/tzdb/backward
They should rarely change (in contrast to the actual TZDB data) so it might be acceptable to bake this list in.

If the tzdata source file is available (for example /usr/share/zoneinfo/tzdata.zi included in many tzdata installations), we could parse links from there.

[ysbaddaden]

We should probably change the references to the current name instead.

Let's do that.

We should make Crystal's time zone loader aware of backwards compatibility aliases

Is that really worth it, though? This is a system issue and the debian maintainers decide to break the systems. Why should developers bother to fix that, when, I suppose, the intent of the change is to move on to the actual names? Though, frankly, breaking the system for a few dozens symlinks is stupid.

[straight-shoota]

Is that really worth it, though?

I would think so, probably. Might be a good idea to look at how other libraries handle this.
These aliases still exist in the upstream database for a reason. Even though nobody should use them, they are still in use (case in point: this repository).

I don't quite undestand the reasoning why removing a couple of symlinks is such a big improvement for cleaning up.
But tzdata package does not entirely abolish these aliases. It only dropped them in the specific data format we're using, the exported zoneinfo directory with TZif. The aliases are still listed in the tzdata.zi source file.

It might be fine to just leave this, though.

[ysbaddaden]

From the tzdata-legacy package:

This package also contains legacy timezone symlinks that are not following the current rule of using the geographical region (continent or ocean) and city name.

Which in turn removes CET, CST, ... 😮‍💨

I still believe this a system issue. There are no reasons for every single application to have to fix something that shall be fixed globally by installing tzdata-legacy and that would fix every application.

Or we consider the symlinks to be untrustable, and we always use the tzdata.zi file.

[straight-shoota]

Or we consider the symlinks to be untrustable, and we always use the tzdata.zi file.

The problem is that this file cannot always be expected to be available. Symlinks are still the basic platform we should build on.

[ysbaddaden]

I guess it depends on how we use the TZ.

For example do we fail with "no such location" when we try to change the TZ for a time whose original location don't follow the "geographical rule" and for which whose symlinks don't exist? For a server application, they can just install the tzdata-legacy but for a distributed binary it might not work correctly.

[straight-shoota]

This is not about TZ in particular. Time zone names can come from anywhere, including user input.

[straight-shoota]

Jiff has an experimental zic parser: https://github.com/BurntSushi/jiff/blob/71ea43d41a3f69be6d0bec1e2ac57a012e26857f/src/tz/zic.rs
But so far it's not used. And according to the comments in that file it seems like it might never be.

But I suppose it could be used to read at least the link syntax in tzdata.zi.

@BurntSushi Have you considered what to do in Jiff when legacy symlinks are missing?

[BurntSushi]

I do some day hope to make the zic parser work. I'm still unsure of whether it will be used at runtime or not.

In any case, I've tended to view this as a system problem, as expressed by others here. This isn't a view I hold strongly. But the fact is that the tzdb can be built in a lot of different ways that impact both semantics and performance.

What I'd normally recommend to users of Jiff who want a more consistent tzdb that doesn't rely on the system zoneinfo database is to enable bundling of the tzdb into the binary. You lose the ability for your application to have independent updates to time zone transitions, but in exchange you know exactly what you get in terms of time zones (and Jiff's bundled tzdb does include the legacy links).

[ysbaddaden]

This is not about TZ in particular. Time zone names can come from anywhere, including user input.

Ah, sorry, I didn't mean ENV["TZ"] but any time with a named location instead of an offset. In that case, missing the backward links meaning we can't translate the time to UTC or whatever because the time's zone is CET or America/Buenos_Aires is a problem. We can't always control the system where an application may run 😢

[HertzDevil]

We can do it for Windows, since we do maintain our own partial database, but the legacy canonical names aren't there to begin with (unless we build spec/std/data/zoneinfo.zip differently)