Thread: pgsql-server/src/backend/utils/adt datetime.c
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@postgresql.org 02/09/03 15:46:32
Modified files:
src/backend/utils/adt: datetime.c
Log message:
Work around mktime() brain damage in recent versions of glibc by using
a series of localtime() calls to determine the local timezone offset
when mktime() fails. This eliminates regression failures on RHL 7.3,
and should continue to work until it occurs to the glibc boys to break
localtime() as well. By then I hope we'll have our own timezone code...
> CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: tgl@postgresql.org 02/09/03 15:46:32 > > Modified files: > src/backend/utils/adt: datetime.c > > Log message: > Work around mktime() brain damage in recent versions of glibc by using > a series of localtime() calls to determine the local timezone offset > when mktime() fails. This eliminates regression failures on RHL 7.3, > and should continue to work until it occurs to the glibc boys to break > localtime() as well. By then I hope we'll have our own timezone code... I think this closes bug #630 as well (inserting data at 2am on a timzone shit). -sc -- Sean Chittenden
This is great! --------------------------------------------------------------------------- Tom Lane wrote: > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: tgl@postgresql.org 02/09/03 15:46:32 > > Modified files: > src/backend/utils/adt: datetime.c > > Log message: > Work around mktime() brain damage in recent versions of glibc by using > a series of localtime() calls to determine the local timezone offset > when mktime() fails. This eliminates regression failures on RHL 7.3, > and should continue to work until it occurs to the glibc boys to break > localtime() as well. By then I hope we'll have our own timezone code... > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom, is there some standard they can point to to break localtime() too? --------------------------------------------------------------------------- Sean Chittenden wrote: > > CVSROOT: /cvsroot > > Module name: pgsql-server > > Changes by: tgl@postgresql.org 02/09/03 15:46:32 > > > > Modified files: > > src/backend/utils/adt: datetime.c > > > > Log message: > > Work around mktime() brain damage in recent versions of glibc by using > > a series of localtime() calls to determine the local timezone offset > > when mktime() fails. This eliminates regression failures on RHL 7.3, > > and should continue to work until it occurs to the glibc boys to break > > localtime() as well. By then I hope we'll have our own timezone code... > > I think this closes bug #630 as well (inserting data at 2am on a > timzone shit). -sc > > -- > Sean Chittenden > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Sean Chittenden <sean@chittenden.org> writes:
> I think this closes bug #630 as well (inserting data at 2am on a
> timzone shit). -sc
That would be cool. I don't have a freebsd machine to try it on though;
can you check CVS tip and see?
FWIW, I get
regression=# select timestamptz '2002-4-7 2:0:0.0';
timestamptz
------------------------
2002-04-07 03:00:00-04
(1 row)
but I got that (on HPUX) before the change too. I think it's correct
--- essentially, given an "impossible" time in the spring-forward gap,
we choose to assume that it is meant as local standard time. (In the
other case at fall-back boundaries, an ambiguous time is likewise
taken as standard time not DST.)
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, is there some standard they can point to to break localtime() too?
I dunno. Logically, if mktime cannot validly output a negative time_t,
then a negative input to localtime isn't valid either. However, there
is no defined "failure" return from localtime, so it would not be easy
to simply arbitrarily refuse the input value. What is more likely to
happen is that at some point localtime will start interpreting its input
as an unsigned offset from 1970, so that what we think is a time in 1969
will come out as a time in 2039 or so.
We really want to be out from under the C-library timezone API before
then ... the silly thing is that the amount of cruft that exists in
the timezone code to cope with Unix-compatible APIs is probably
comparable to the amount of extra functionality we'd need to write to
avoid depending on the C library's time routines. We already do most of
our own time arithmetic --- we are essentially *only* depending on the
C library to answer the question "what timezone is this local time in",
ie "what are the DST rules"?
regards, tom lane
> > I think this closes bug #630 as well (inserting data at 2am on a > > timzone shit). -sc > > That would be cool. I don't have a freebsd machine to try it on though; > can you check CVS tip and see? > > FWIW, I get > > regression=# select timestamptz '2002-4-7 2:0:0.0'; > timestamptz > ------------------------ > 2002-04-07 03:00:00-04 > (1 row) > > but I got that (on HPUX) before the change too. I think it's correct > --- essentially, given an "impossible" time in the spring-forward gap, > we choose to assume that it is meant as local standard time. (In the > other case at fall-back boundaries, an ambiguous time is likewise > taken as standard time not DST.) Looks like this works on HEAD. -sc -- Sean Chittenden