Paul Eggert wrote: > >>> tzname is used in three places: > >>> - time_rz, > >> > >> This should be fixed to use strftime instead. > > > > This seems wrong for two reasons: > > > > * time_rz is a small module, without textual I/O. > > Fair enough, and the changes I recently installed into Gnulib solved > this problem in a different way, which make time_rz even smaller. As you > suggested, the updated time_rz does not use strftime.
Glad it worked out. Thanks! > > * It is bad design to require calling a complicated function > > in order to get elementary data about something. > > True, but unfortunately strftime %Z is the only widely supported and > portable way to get the time zone abbreviation. 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. 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? > In the long run I suppose we can assume struct tm's tm_zone instead. But > this is standardized only in POSIX.1-2024, and for many years apps will > need to deal with less-capable systems, notably Microsoft Windows. > > We could create a new module to get a time zone abbreviation. It could > define a new function that is given BUF, SIZE, TM and TZ and would be > the equivalent of strftime (BUF, SIZE, "%Z", TM) in the timezone TZ And the caller has to try different TM values? Why not a function that takes an index in [0, 1], like tzgetname() does? > 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). - We might need this module in order to implement (or speed up?) the API that we are discussing above. > it wrongly assumes > that there are at most two time zone abbreviations for any particular > time zone setting. Oh? Which time zone has 3 or more abbreviations? Bruno
