[tz] zic changes (2/2)
Guy Harris
guy at alum.mit.edu
Thu Mar 3 02:43:50 UTC 2016
On Mar 2, 2016, at 6:08 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> Brian Inglis wrote:
>> On 2016-03-02 16:19, Ian Abbott wrote:
>>> On 03/02/16 23:02, Paul Eggert wrote:
>>>> The TZ string "PST+8PDT" doesn't conform to POSIX,
>>> It doesn't?
>>
>> It does appear to conform - see:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
>
> It "conforms" in the sense that its syntax matches the POSIX spec. However, no semantics are specified by POSIX for what daylight-saving rules are in effect when TZ="PST+8PDT" is in the environment. Glibc is within its rights, for example, to assume that DST in effect only one second during the year -- or even not in effect any time.
The same, of course, applies to PST8PDT and so on; it's not as if the "+" is somehow magical. (I presume Aurelien put it in there to force the glibc time zone code *not* to treat the TZ value as a tzdb compiled file name.)
> I vaguely recall older versions of POSIX not allowing the syntax "PST+PDT", though I could be wrong. I imagine the current POSIX spec is simply a typo, since I can't imagine that it's intended for users to employ a syntax whose semantics are unspecified.
"Typo" as in "the string 'stdoffset[dst[offset][,start[/time],end[/time]]]' was intended to be 'stdoffset[dst[offset],start[/time],end[/time]]', but somebody accidentally put the square brackets in wrong", so that the you can omit everything after "stdoffset", or you can have "dst..." and omit the offset and/or the end times, but if you specify "dst" you can't omit the start and end values"?
> Also, I think it's a glibc bug, in the sense that I don't think the current behavior is intended by the glibc maintainers. Still, portable programs shouldn't use TZ="PST+8PDT" or TZ="PST8PDT" or anything like that.
What about portable users? :-)
More information about the tz
mailing list