🚀 go-pugleaf

msb@sq.com (Mark Brader) writes:

>I say mktime() must yield 1988-07-01 01:00:00 tm_isdst=2
>in this situation on this implementation.

OK.  But then suppose the implementation uses a different encoding for
tm_isdst, as it's entitled to.  That is, suppose it uses tm_isdst=1 for
2 hours and tm_isdst=2 for 1 hours.  This is perverse, but (as shown
below) some non-perverse encodings have similar problems, and I'm
trying to keep the example similar to the previous one.

In that case, to be consistent, it seems that in Newfoundland
you would say that mktime should convert
1995-07-01 00:00:00 tm_isdst=1 to
1995-06-30 23:00:00 tm_isdst=2, since the requested time used 2-hour DST,
whereas in 1995 Newfoundland used 1-hour DST.

(By the way, thanks for seeing through my errors in the previous example --
I had subtracted where I should have added.)


>> And if so, shouldn't mktime make the same sort of adjustment if the
>> implementation uses tm_isdst values of 3600 and 7200 instead of 1 and 2?

>I'm not sure what this means in this context....

The implementation defines the tm_isdst encoding.
So if mktime is supposed to pay attention to this encoding,
then a program that wants daylight savings time should not simply set
tm_isdst to some positive value (like 1); instead the program should
take a tm_isdst value from a previous invocation of localtime or
mktime, and use that value.

Furthermore, this suggests that the program will encounter
implementation-defined behavior if it uses a tm_isdst value
other than one of the values returned by localtime or mktime.
For example, if localtime always returns tm_isdst values of 0, 1200,
1800, 3600, or 7200 (which is plausible behavior on a system that
supports the historical DST offsets), and if mktime is invoked with
tm_isdst set to some other positive value, then mktime can interpret it
as it pleases; for example, it could interpret tm_isdst as the DST
offset in seconds.  This could be useful if the implementation supports
solar time by using a DST offset that varies every so often (as Olson's
tz implementation does).

This is a reasonable and interesting implementation of the standard;
it's one that hadn't occurred to me before this dialog.
However, I don't think it's the only reasonable implementation;
and as far as I know no implementation currently has this behavior.