From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Dann Corbit <DCorbit(at)connx(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Timestamp & Interval - Part 1 |
Date: | 2002-05-22 02:21:28 |
Message-ID: | 3CEB00A8.FC45C078@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-22 03:49:58 | Re: Is 7.3 a good time to increase NAMEDATALEN ? |
Previous Message | Thomas Lockhart | 2002-05-22 02:01:55 | Re: Redhat 7.3 time manipulation bug |