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

[Paul Eggert]

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.