Re: Year 2038 Bug?

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/

In response to

Responses

Browse pgsql-hackers by date

  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?