[tz] Question about bug seen in OpenBSD and FreeBSD related to tzname

Paul Eggert eggert at cs.ucla.edu
Thu Nov 21 01:09:37 UTC 2019

On 11/20/19 2:08 PM, Guy Harris wrote:

> I think the first of those two is at least as valid, if not more valid, than the
> 	tzname[0]: CAT
> 	tzname[1]: CAT
> claimed for TZ=CAT0 on Linux - the POSIX spec says that tzname[1] should be "dst", but "dst" isn't present.

I doubt whether it's a POSIX-conformance issue, as POSIX doesn't say 
what should be in tzname[1] when "dst" is absent. (Perhaps POSIX should 
explicitly say that tzname[1]'s value is undefined in this case, though 
I wish POSIX would deprecate tzname entirely and so am not inclined to 
pursue this.)

I can see arguments either way, for what should be in tzname[1] when TZ 
does not have a "dst" element. For developers, the tzcode/macOS behavior 
(where tzname[1] is "   ") might be better because it provides an 
obvious clue that the program is buggy when it outputs three spaces 
instead of a time zone abbreviation. For end users, the glibc behavior 
(where tzname[1] equals tzname[0]) might be better because if a buggy 
program uses tzname[1] in an environment where "CAT" is always the right 
time zone abbreviation, the buggy program will output "CAT" which 
happens (luckily) to be the correct answer that the user wants.

More information about the tz mailing list