Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
> failure on all platforms; it indicates "don't know", but afaik there is
> no defined behavior for the rest of the fields in that case. Can we be
> assured that for all platforms the other fields are not damaged?
We can't; further investigation showed that another form of the problem
was mktime() setting the y/m/d/h/m/s fields one hour earlier than what
it was given --- ie, pass it 00:00:00 of a DST forward transition date,
get back neither 00:00:00 nor 01:00:00 (either of which would be
plausible) but 23:00:00 of the day before!
What I did about this was to coalesce all of the three or four places
that use mktime just to probe for DST status into a single routine
(DetermineLocalTimeZone) that is careful to pass mktime a copy of the
original struct tm. No matter how brain dead the system mktime is,
it can't screw up the other fields that way ;-). Then we trust
tm_isdst and tm_gmtoff only if tm_isdst >= 0. Possibly we'll find
that it'd be a good idea to test also for return value == -1, but
the tm_isdst test seems to be sufficient for the known bug cases.
> Not sure how much code we should put in to guard for cases we can't even
> test (RH 5.1 is pretty old).
Yeah, but the above-described behavior is reported on RH 7.1 (by two
different people). I'm afraid we can't ignore that...
regards, tom lane
