Re: Timestamp & Interval - Part 1 - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: Timestamp & Interval - Part 1
Date
Msg-id 3CEB00A8.FC45C078@fourpalms.org
Whole thread Raw
In response to Re: Timestamp & Interval - Part 1  ("Dann Corbit" <DCorbit@connx.com>)
List pgsql-hackers
> Why not fix it completely with this stuff:
> ftp://elsie.nci.nih.gov/pub/
> Just an idea.

Ah, the real zic implementation. afaik this is public domain or BSD or
at least compatible with our BSD license wrt distribution.

Great idea. We may end up doing this! Though I hate for the project to
pick up the task of maintaining sync with that distro.

We already have a NO_MKTIME_BEFORE_1970 #define'd for AIX and IRIX
(always paragons of standard behavior :/ Funny enough it doesn't
actually guard the mktime() code, since I think that there is a good
signature from the exit from mktime() on those systems (independent of
the return value) to detect that there is a problem. glibc is sinking to
new depths in lack of support for this feature by brute force exiting
early on.

It looks like we might (easily?) get good behavior beyond y2038, since
we might be able to redefine time_t within our code. At the moment zic
looks for it from sys/types.h, but maybe we could isolate it and force
it to be a 64-bit number on systems which support it. Hmm, need to find
how to translate current system time to that representation...
                     - Thomas


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Redhat 7.3 time manipulation bug
Next
From: Tom Lane
Date:
Subject: Re: Is 7.3 a good time to increase NAMEDATALEN ?