🚀 go-pugleaf

> > If you wanted the time one day later, you would have set tm_isdst to -1.
> 
> I don't see how this follows.  If I want the time one day later,
> the natural thing for me to do is to add 1 to tm_mday.  ...

Even if this point is accepted, it only argues as to how the interface to
mktime() *should* have been designed.

But note that the primary purpose of mktime() is to make a time_t from
a struct tm -- that's where its name comes from, after all -- and this
is what its interface is designed for conveniently doing.  And one aspect
of that design is that you have to make sure that *all* the struct members
(except tm_yday and tm_wday) have the correct values for what you want to
ask mktime() to do.  And this is why the "natural thing" quoted above is
wrong.

In any case, is it really sensible to argue from naturalness about a
function where you specify the date 2001-01-01 by setting the members
tm_year, tm_mon, and tm_mday to 101, 0, and 1 respectively?  :-) * 0.25

As to what the standard implies or not or intends to imply or not, please
see Larry Jones's article in another branch of the thread.

> > an implementation that could deal with Newfoundland could legitimately
> > use distinct positive values for tm_isdst to indicate the 2-hour DST
> > of 1988 vs. the 1-hour DST of other years.
> 
> An interesting idea, and it leads to interesting probl... -- er, I mean
> consequences.  For example, the C Standard allows an implementation
> where localtime sets tm_isdst to the DST offset in seconds.
> But then suppose we have such an implementation, and suppose that the
> user is in US Pacific time and invokes mktime on 1995-01-01 00:00:00
> tm_isdst==1.  Then the most logical result for mktime, if we follow
> what you seem to be saying, would be 1994-12-31 23:59:59 tm_isdst==0.
> 
> I think the C Standard allows this behavior as well.  But then I'm
> pretty permissive in these matters.  After all, the standard says ``The
> local time zone and Daylight Saving Time are implementation-defined.''
> This means that pretty much anything goes.

If unconstrained, it might.  But right before that, it defines the terms:

#  ... "local time" ... is the calendar time expressed for some specific
#  time zone, and ... "Daylight Saving Time" ... is a temporary change
#  in the algorithm for determining local time.

In other words, the implementation must produce the correct local time
in some specific time zone, whether DST is in effect or not, and the DST
algorithm must actually reflect reality in that zone.  An implementation
is allowed to set the member tm_isdst to 3600 or 7200 according to the
amount of DST in effect that year, but it must do something sensible
if the programmer changes tm_isdst to some other positive value.

Hence, in this implementation, the input equivalent to 1995-01-01 00:00:00
tm_isdst=1 must still produce the result equivalent to 1994-12-31 23:00:00
tm_isdst=0 for the US Pacific time zone, and should (in an implemenation
of acceptable quality) produce the same result for the Newfoundland zone.
-- 
Mark Brader, msb@sq.com             "Ask not for whom the compiler waits;
SoftQuad Inc., Toronto               it waits for thee."   -- Henry Spencer

My text in this article is in the public domain.