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.
strftime is a large module, doing string formatting.
If time_rz depends on strftime, we have a circular dependency between
a small and a large module. Thus, time_rz is no longer slim.
This would be a bit like using asprintf ("%s%s", s1, s2) to compute
the concatenation of two strings s1 and s2.
* It is bad design to require calling a complicated function
in order to get elementary data about something.
We see the result in fnmatch and regex regarding the collation
order: libc has no accessors for the LC_COLLATE data, thus it is
hard to retrieve the collation data from the underlying libc.
Or the implementation of the decimal_point function: One needs to
format an entire number using sprintf, in order to retrieve one
character. Again, due to lack of an appropriate API.
> > - parse-datetime,
>
> Likewise. (This usage of tzname is simply wrong, by the way, but it can
> be compatibly wrong.)
That would require two (!) strftime calls, one to get the time zone
without DST abbrev, and one to get the time zone with DST abbrev. This is
gross.
> > POSIX:2024 (p. 2310-2311) does not warn against these 3 variables.
>
> That's a bug in POSIX and a fix is already in the pipeline
> <https://austingroupbugs.net/view.php?id=1816>.
Ah, I see.
> > "tm_zone points to static storage and may be overridden on
> > subsequent calls to localtime(3) and similar functions (however,
> > this never happens under glibc)."
>
> The actual lifetime in all implementations is that it's good at least
> until you set TZ. Glibc extends this so that it's good forever.
>
> Not covering the lifetime issue is also a bug in POSIX and I'm working
> with the committee on getting it fixed.
+1.
Bruno
