Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lockhart(at)fourpalms(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
Date: 2001-05-10 13:55:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
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 LaneDate: 2001-05-10 14:12:49
Subject: Re: AW: Coping with huge deferred-trigger lists
Previous:From: Bruce MomjianDate: 2001-05-10 13:39:44
Subject: Re: Re: Is `#!/bin/sh' configurable?

pgsql-bugs by date

Next:From: AlbertDate: 2001-05-10 15:06:30
Subject: Bug in plpgsql with execute ...
Previous:From: Thomas LockhartDate: 2001-05-10 13:22:32
Subject: Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group