| 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: | Whole Thread | Raw Message | 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? |