Re: Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

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