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.