On 2024-06-17 06:47, Bruno Haible wrote:
@item
This variable's contents are unreliable if you use a geographical
@env{TZ} setting like @code{TZ="America/Los_Angeles"}.
What do you mean by "unreliable"?
You'll get different results on different platforms, the tzname values
may not be what you want, and behavior is undefined if different threads
call localtime etc. at about the same time, even if the program never
changes TZ. For example, run this with TZ="Europe/London":
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
int
main ()
{
const char *tz = getenv ("TZ");
time_t epoch = 0;
localtime (&epoch);
printf ("TZ=%s -> tzname[0]=\"%s\", tzname[1]=\"%s\"\n",
tz != NULL ? tz : "(null)",
tzname[0], tzname[1]);
}
On GNU/Linux you'll get this:
TZ=Europe/London -> tzname[0]="BST", tzname[1]="BST"
but musl says tzname[0]="GMT". Both behaviors conform to POSIX. The
glibc behavior is arguably nicer for single-threaded apps, but it's
debatable. The POSIX folks, partly at my instigation, have wisely thrown
up their hands about this, which is partly why tzname is planned to be
removed.
I hope this helps to explain why Gnulib and GNU apps should (and
generally do) avoid tzname.
