Re: pgsql-server/src/backend/utils/adt datetime.c - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql-server/src/backend/utils/adt datetime.c
Date
Msg-id 17875.1031087559@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql-server/src/backend/utils/adt datetime.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-committers
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

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql-server/src/backend/utils/adt datetime.c
Next
From: petere@postgresql.org (Peter Eisentraut - PostgreSQL)
Date:
Subject: pgsql-server/ /configure /configure.in ontrib/ ...