🚀 go-pugleaf

scjones@thor.sdrc.com (Larry Jones) writes:

>eggert@twinsun.com (Paul Eggert) writes:
>> All the standard says (in a footnote) is that mktime must
>> ``presume initially that Daylight Savings Time ... is ... in effect
>> for the specified time''.  The standard does not say what mktime does
>> if this presumption is impossible to satisfy.

> What does it mean to say that a presumption is impossible to satisfy? 

By that phrase, I meant that the presumed initial time, isdst flag and all,
never existed (or never will exist, as the case may be).

> mktime is to presume that DST is in effect for the specified time.  If,
> after normalizing the values, it discovers that DST is not in effect at
> that time (i.e., the presumption was false), then it must further
> adjust the time

So far we're in agreement -- though the standard is murky even here.
I'm writing from memory here, since my copy of the standard is at work,
but I recall that the standard says only that out-of-range time values
should be accepted; it doesn't say what should be done with them.

Further, the standard says that local time and DST are
implementation-defined, which gives the implementation wide latitude
about what to do here.  I agree that the only reasonable interpretation
for ``Feb 0'' is ``Jan 31'', but when there are multiple reasonable
interpretations, I don't see where the standard requires one or the other.

> by the appropriate DST offset and clear the flag.

I still don't see where the standard requires this.
There is another plausible way to adjust the time, i.e. simply clear the flag.
This is better for many common cases (e.g. the ``add 1 day'' example),
and it avoids genuine ambiguity in some uncommon but real examples
(not just Newfoundland in 1988-1989, but also Uruguay between 1970 and 1974,
the Dominican Republic between 1967 and 1969, and so forth).