tzname sometimes doesn't get set right

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

tzname sometimes doesn't get set right

Andras Farkas
tzname doesn't always get set.  Assuming it's meant to be
POSIX-compliant (not necessarily XSI/SUS here, but POSIX) then the
following behavior is buggy:
Doing the following:

export TZ=CAT0
cat > daytime.c <<EOF
#include <stdio.h>
#include <time.h>

int main(void)
{
        tzset();
        printf("tzname[0]: %s\n", tzname[0]);
        printf("tzname[1]: %s\n", tzname[1]);
        /*
        printf("daylight: %d\n", daylight);
        printf("timezone: %ld\n", timezone);
        */
}
EOF
cc daytime.c
./a.out

The following is the output:

tzname[0]:
tzname[1]:

nota bene: both of those aren't null/empty, they're three spaces.
This is incorrect, as CAT0 is a valid value of TZ.  If we set it to
CAT0DOG0 instead, the output changes dramatically:

tzname[0]: CAT
tzname[1]: DOG

This is the expected output for when TZ is CAT0DOG0.
Back to TZ just being CAT0, a friend using GNU/Linux was able to show
me the output there:

tzname[0]: CAT
tzname[1]: CAT

If I read POSIX correctly, GNU's implementation and output are correct
here.  This is the output I expect.

I found FreeBSD's output was also buggy, in a different way:

tzname[0]: EST
tzname[1]:

I'll be sending them a bug report too.

References:
https://man.openbsd.org/ctime.3
https://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html

Reply | Threaded
Open this post in threaded view
|

Re: tzname sometimes doesn't get set right

Andras Farkas
I've confirmed that this bug isn't present in upstream tzcode, at
least not in release 2019c
With upstream tzcode on OpenBSD, the results are:
tzname[0]: CAT
tzname[1]:
(three spaces for the latter value)

Discussion had there:
http://mm.icann.org/pipermail/tz/2019-November/028596.html
http://mm.icann.org/pipermail/tz/2019-November/thread.html

The FreeBSD bug report I also made after sending the OpenBSD bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241978