Re: First draft of the Y2038 design document

[Rich Felker <dalias at libc dot org>]

On Sun, Nov 01, 2015 at 06:34:10PM -0800, Paul Eggert wrote:
> 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.

The behavior of functions that depend on the timezone is
implementation-defined for such zones. The behavior of functions that
do not depend on timezone, however, is not permitted to vary in this
way. The gmtime function is strictly specified to perform an exact
mathematical operation:

    "The relationship between a time in seconds since the Epoch used
    as an argument to gmtime() and the tm structure (defined in the
    <time.h> header) is that the result shall be as specified in the
    expression given in the definition of seconds since the Epoch (see
    XBD Seconds Since the Epoch), where the names in the structure and
    in the expression correspond."

Source:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime.html

Implementations which do otherwise are non-conforming. I don't know
what "clearer wording" you could be looking for.

> >>>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.

For localtime_r this is permitted because it's specified to depend on
the environment variable; calls made concurrently with modification to
the environment are not safe, as stated in the text I quoted earlier:

    "Since multi-threaded applications are not allowed to use the
    environ variable to access or modify any environment variable
    while any other thread is concurrently modifying any environment
    variable, any function dependent on any environment variable is
    not thread-safe if another thread is modifying the environment;
    see XSH exec."

However gmtime_r is not specified to use the environment and thus is
not subject to such restriction.

Rich