From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Year 2038 Bug? |
Date: | 2008-10-13 18:24:15 |
Message-ID: | 48F3924F.8050804@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David E. Wheeler wrote:
> On Oct 13, 2008, at 11:13, Tom Lane wrote:
>
>> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>>> Probably no problem, then. Do dates in PostgreSQL work for their
>>> entire documented ranges on 32bit processors?
>>
>> As long as the C compiler supports int64 ...
>
> I was afraid you'd say that. See:
>
> http://code.google.com/p/y2038/wiki/WhyBother
>
> Especially the "64 bit CPU doesn't mean 2038 clean" section. Again,
> maybe this doesn't apply to PostgreSQL; I'm just doing a bit of
> diligence. :-)
>
> Cheers,
>
> David
>
PostgreSQL doesn't use the standard time_t and time functions for its
timestamp types. Therefore, any limitations in regards to 64-bit time_t
values on 32-bit platforms don't apply; other than the limitation Tom
spoke of ... no 64-bit int.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2008-10-13 18:33:19 | Re: Year 2038 Bug? |
Previous Message | Zdenek Kotala | 2008-10-13 18:22:56 | Re: Year 2038 Bug? |