Re: [PATCH] manual: Add more documentation for the tm_isdst member of struct tm

[Paul Eggert <eggert@cs.ucla.edu>]

On 2022-10-25 11:07, Florian Weimer wrote:

> I think in other cases, tz goes with actual practices on the ground

There is no real practice on the ground here, as nobody outside of libc 
nerds cares (or should care) whether tm_isdst is zero or positive.


> I'm just trying to follow the line of thought.

It's the same line of thought that Morocco uses. The ordinary time is 
the time observed most of the year. The unusual time is daylight saving 
time (or "alternative time", as POSIX sometimes puts it) and is observed 
during winter, or during Ramadan, or whatever. Other countries have done 
similar things in the past.


>> PS. While we're on the subject of documentation, perhaps we should
>> also mention that mktime can use tm_gmtoff to disambiguate
>> otherwise-ambiguous time stamps. This is reliable even for situations
>> like Volgograd in 2020, and it conforms to POSIX. A bit tricky to
>> document, though.
> 
> Huh.  How can we do this tm_gmtoff thing without breaking C
> compatibility?  I'm worried that a conforming application might not
> initialize tm_gmtoff (or rather __tm_gmtoff) properly.

It doesn't break compatibility if tm_gmtoff is inspected only when 
tm_isdst doesn't resolve the ambiguity. At that point, if tm_gmtoff 
matches the tm_gmtoff of one of the two plausible timestamps, mktime can 
use that info to choose which one. It's OK if the input tm_gmtoff is 
uninitialized, as mktime could choose that one anyway. (Though it's 
officially undefined behavior to access uninitialized memory, in 
practice it's OK here.)

With this approach, mktime is always the inverse of localtime even in 
cases like Volgograd, which is a clear win. Cute, huh? Though not 
currently documented.