mktime problems when adjusting tm_isdst
kre at munnari.OZ.AU
Tue Oct 10 16:33:02 UTC 1995
I doubt that any patch can reasonably help here, the tm_isdst
flag as input to mktime() is simply absurdly badly broken as
defined. In anything other than the simplest cases, there is
no rational way to make it work as defined, it would probably
be better for mktime() to either simply ignore it (not great),
or return an error ((time_t)-1) or ((time_t)0) if tm_isdst is
set to the "wrong" value.
The only reason this brain damage exists at all is because of
the silly desire to make arithmetic on times be done by doing
arithmetic on the fields of a struct tm. OK, it is not a good
idea to assume that a time_t is always an arithmetic type, but
a bunch of macro/function definitions for addition/subtraction
of time_t's from each other, and integers to/from time_t's would
have been a much more rational choice, and much easier to use.
Its all great that one should attempt to support the standardised
interfaces, however brain dead they actually are, but having
attempted that, and discovered that there is simply no way to
implement it correctly, there comes a time when the right answer
is simply to abandon the attempt, and not continue to pretend
that it can be done, and rely on people not finding the hard
cases where it can't.
The case where tm_isdst == 1, and summer time is not actually in
effect, is basically asking mktime() to invent policy. The
request to it is "If daylight saving had been in effect at
this time I am telling you, the time would have been this. So,
what is it really?" This is meaningless, it requires knowledge
as to what the non-existant daylight time shift would have been,
had it existed. One can invent any offset at all for that, for
all anyone knows for sure, the answer Paul originally sent for
the conversion that "went wrong" might be perfectly correct.
Note however that the other way (tm_isdst == 0) can be handled,
as that is saying "this time is standard time for the zone,
correct it for any DST that might have been in effect", and
as long as the time is one in the past, or very near future,
it is possible (times in the far future, where far is anything
beyond about 3 months, are always going to be impossible).
If any patch is needed, simply make it be an error - or if you
want to allow a little more latitude, you may be willing to
assume that when the nearest DST before the time involved, and
the nearest after the time involved are the same, then it is
acceptable to assume that the same offset is what would have
applied in the gap between, had there been DST then, and only
return the error in cases where the offset was not the same in
the two cases.
More information about the tz