[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