| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(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:22:56 |
| Message-ID: | 48F39200.10001@sun.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David E. Wheeler napsal(a):
> 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. :-)
PostgreSQL 8.4 uses 64bit data type for time. But if you use system timezone
then you can get in trouble if system does not support 64bit zic files.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Chernow | 2008-10-13 18:24:15 | Re: Year 2038 Bug? |
| Previous Message | David E. Wheeler | 2008-10-13 18:19:27 | Re: Year 2038 Bug? |