🚀 go-pugleaf

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

>	Thus, a positive or zero value for tm_isdst causes the mktime
>	function to presume initially that Daylight Saving Time,
>	respectively, is or is not in effect for the specified time.
> This corresponds to your first interpretation....

I think it also corresponds to my second interpretation, which presumes that
DST is (or is not) in effect unless the presumption cannot be satisfied.

> Your second interpretation would produce incorrect results
> when such calculations crossed DST boundaries.

That depends on what one means by ``correct''.  For example, suppose
I am using US Pacific time, and I want the time ``one day after
1993-10-31 00:00:00 tm_isdst=1'', so I pass the struct tm equivalent of
1993-10-32 00:00:00 tm_isdst=1 to mktime.  The clock jumps back an hour at
1993-10-31 02:00:00.  Should mktime return
1993-10-31 23:00:00 tm_isdst=0 (1), or
1993-11-01 00:00:00 tm_isdst=0 (2)?

The first interpretation yields (1), and the second interpretation yields (2).
In this case, (2) is more ``correct'',
in the sense that it corresponds better to what was expected.

One way to think about the issue is that it depends on whether the
tm_isdst field is considered to be less significant or more significant
than the other tm_* fields, in the sense that the tm_min field is more
significant than the tm_sec field.  If tm_isdst is less significant
than the other fields (the first interpretation), then when tm_isdst is
out-of-range, one should adjust the other fields accordingly (just as
when tm_sec is out-of-range, one has to adjust the more significant
fields accordingly).  If tm_isdst is more significant than the other
fields (the second interpretation), then bringing tm_isdst into range
doesn't affect the lesser fields.

I think there are cases where the first interpretation matches
intuition better than the second one does, but the point is that
neither interpretation is uniformly better than the other, and I don't
see why the standard requires one interpretation over the other.


I fear that mktime is murky in other respects, too.  For example,
I don't know what the standard means when it says ``the final
value of tm_mday is not set until tm_mon and tm_year are determined.''