Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-05-10 14:12:49|
|Subject: Re: AW: Coping with huge deferred-trigger lists |
|Previous:||From: Bruce Momjian||Date: 2001-05-10 13:39:44|
|Subject: Re: Re: Is `#!/bin/sh' configurable?|
pgsql-bugs by date
|Next:||From: Albert||Date: 2001-05-10 15:06:30|
|Subject: Bug in plpgsql with execute ...|
|Previous:||From: Thomas Lockhart||Date: 2001-05-10 13:22:32|
|Subject: Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and
released on Tuesday ...)|