First draft of the Y2038 design document

[Paul Eggert]

Szabolcs Nagy wrote:
>>
>> it's a requirement that conforming applications cannot set TZ to a value
>> like "right/America/Los_Angeles",
>> at all times. This is not a requirement that a conforming application can
>> blithely ignore merely because it's
>> currently executing certain functions. This is clearly stated in the
>> environment-variable section.
>>
>
> That argument does not work if TZ is set to
> ":right/America/Los_Angeles", which a conforming
> application may do.

That's a reasonable caveat.  Even there, though, if the glibc manual says that 
setting TZ to ":right/America/Los_Angeles" affects the interpretation of leap 
seconds (and therefore the behavior of gmtime_r), this would arguably fall under 
the umbrella of implementation-defined behavior.  At any rate, several 
implementations (not just glibc) have this behavior, and if POSIX were intended 
to prohibit it I would expect clearer wording to that effect.

>>> In any case glibc does not do this but just
>>> gets it wrong on the matter of permitted vs forbidden side efficts.
>>
>> This seems to be veering into a different area, where perhaps there is a glibc
>> bug (presumably which can be
>> illustrated by using only POSIX-specified TZ values), but that's a different
>> matter.
>>
>
> if one thread changes TZ=GMT0 to TZ=GMT-1 while
> another concurrently calls gmtime_r, then glibc
> introduces a data race when it calls getenv("TZ").

Surely any such data race will exist with localtime_r, too. If there's a bug in 
this area a bug report should be filed, and fixing the bug will most likely fix 
both localtime_r and gmtime_r.