On 2024-06-17 08:32, Bruno Haible wrote:
NetBSD has a tzgetname() function: https://man.netbsd.org/tzset.3
tzgetname (tz, i) is equivalent to tzname[i].
This is the style of API I like better.
That API can't work in general. Some time zones have multiple
abbreviations for standard time. A clue to the problem is the
documentation's "The return values for both tzgetname() and
tzgmtoff() correspond to the latest time for which data is available,
even if that refers to a future time." This is obviously a bad thing.
Still, what about internationalization of time zone names? For example,
in German, we write "MEZ" instead of "CET", and "MESZ" instead of "CEST".
In <https://data.iana.org/time-zones/tz-link.html#notation> you
reference CLDR. That sounds like something could be implemented here...
Is there already an API for retrieving localized time zone names
somewhere?
Not that I know of. CLDR may have something.
And the caller has to try different TM values? Why not a function that
takes an index in [0, 1], like tzgetname() does?
Because there are typically more than two abbreviations. Even
Europe/Berlin, which is relatively stable, has had four (CET, CEST,
CEMT, LMT) and may have more if the EU daylight-saving changes that are
in the legislative pipeline ever actually happen.
Regardless of whether we add such a module, though, we should remove the
tzname module from Gnulib, as Gnulib doesn't need it any more and nobody
should use it. Proposed patch attached.
No, please leave it as is:
- It is needed for portability to native Windows. Even though you say
that tzname is problematic, it is in the POSIX standard, and apps
may want to use it (despite the warnings in the doc).
Apps really, really shouldn't use tzname. And POSIX plans to remove
tzname in a future edition.
- We might need this module in order to implement (or speed up?) the
API that we are discussing above.
Gnulib shouldn't use tzname even for our own internal APIs.
