From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql-server/src/backend/utils/adt datetime.c |
Date: | 2002-09-03 21:12:39 |
Message-ID: | 17875.1031087559@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut - PostgreSQL | 2002-09-03 21:45:45 | pgsql-server/ /configure /configure.in ontrib/ ... |
Previous Message | Tom Lane | 2002-09-03 21:02:30 | Re: pgsql-server/src/backend/utils/adt datetime.c |