Hi!
On Wed, 2019-10-30 at 13:09:33 +0000, Colin Watson wrote:
> First, is this a distinction with a meaningful difference worth spending
> the time on changing it?
Depends, I guess. See below.
> Second, it is not correct to say that the format requires an offset.
> Referring to timezone(3), the format being used is not the first one
> ("std offset[dst[offset][,start[/time],end[/time]]]", which I'll call
> the "systematic format" below), but the second:
>
> The second format specifies that the timezone information should
> be read from a file:
>
> :[filespec]
>
> If the file specification filespec is omitted, or its value
> cannot be interpreted, then Coordinated Universal Time (UTC) is
> used. If filespec is given, it specifies another
> tzfile(5)-format file to read the timezone information from. If
> filespec does not begin with a '/', the file specification is
> relative to the system timezone directory. If the colon is
> omitted each of the above TZ formats will be tried.
>
> This documentation is IMO poorly drafted, but if you read all of it
> rather than just the pseudo-grammar, it's clear that the colon may in
> fact be omitted, and in this case it therefore refers to a file name
> relative to the system timezone directory, namely
> /usr/share/zoneinfo/UTC. Perfectly fine.
Sorry, it seems I didn't make my case clear when I sent that mail, and
also grabbed the first reference I recalled I had at hand.
So, the timezone(3) man page documents (more or less, as I agree it's
not very clear), the current glibc-specific behavior, which obviously
matches its code (see «time/tzset.c:tzset_internal()»).
This does not match what the glibc manual says, nor what POSIX
specifies:
«info libc TZ»
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html>.
There, it's clear that «:CHARACTERS» is parsed in an implementation
defined way, so simply using that form is non-portable. The addition of
ignoring the colon and parsing it in the implementation defined way is
probably just non-conformant, and thus even less portable. :)
Other systems document behavior similar to glibc, others do not:
<http://man.openbsd.org/tzset>
<https://www.freebsd.org/cgi/man.cgi?query=tzset>
<https://netbsd.gw.com/cgi-bin/man-cgi?tzset>
> Since TZ=UTC is technically correct per timezone(3), I'd stick with it
> unless there's a demonstrable practical difference (perhaps
> compatibility on some odd systems?) justifying the effort involved in
> changing it.
This indeed works in Debian, but I think it's strictly speaking
incorrect according to POSIX, and as such is non-portable.
This is something I got aware of relatively recently (I see the git
commit in dpkg where I fixed this, is from 2017-09), but I cannot
recall from where. I consider making this more visible to be important,
but at the same time I don't think we need to do a mass bug filing
about this given that it does indeed work in Debian. But given that
this is IMO a correctness issue, perhaps a pedantic lintian check
might be appropriate.
Thanks,
Guillem
