Thread: Year 2038 Bug?
Howdy, Not sure if PostgreSQL uses time_t, but if so, this project provides useful code (a drop-in replacement for time.h) to address the 2038 bug on 32-bit platforms. http://code.google.com/p/y2038/ Useful for PostgreSQL? Best, David
"David E. Wheeler" <david@kineticode.com> writes:
> Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
regards, tom lane
On Oct 13, 2008, at 11:01, Tom Lane wrote: > "David E. Wheeler" <david@kineticode.com> writes: >> Not sure if PostgreSQL uses time_t, > > We got rid of that some time ago. Probably no problem, then. Do dates in PostgreSQL work for their entire documented ranges on 32bit processors? Thanks, David
"David E. Wheeler" <david@kineticode.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 ...
regards, tom lane
On Oct 13, 2008, at 11:13, Tom Lane wrote: > "David E. Wheeler" <david@kineticode.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
David E. Wheeler napsal(a): > On Oct 13, 2008, at 11:13, Tom Lane wrote: > >> "David E. Wheeler" <david@kineticode.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
David E. Wheeler wrote: > On Oct 13, 2008, at 11:13, Tom Lane wrote: > >> "David E. Wheeler" <david@kineticode.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/
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote: > 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. I've never noticed a problem with the TZinfo database that ships on systems I've used. How would I know that there was a problem? What sort of trouble could I get into? Thanks, David
On Oct 13, 2008, at 11:24, Andrew Chernow wrote: > 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. Gotcha, thanks for the clarification. Best, David
David E. Wheeler napsal(a):
> On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
>
>> 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.
>
> I've never noticed a problem with the TZinfo database that ships on
> systems I've used. How would I know that there was a problem? What sort
> of trouble could I get into?
when you use --with-system-tzdata and run make check on head it fails on
systemes without 64bit tzinfo support.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
On Oct 13, 2008, at 11:37, Zdenek Kotala wrote: > when you use --with-system-tzdata and run make check on head it > fails on systemes without 64bit tzinfo support. Oh. Is it not preferable to use the tzdata that ships with PostgreSQL? Thanks, David
"David E. Wheeler" <david@kineticode.com> writes:
> On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
>> when you use --with-system-tzdata and run make check on head it
>> fails on systemes without 64bit tzinfo support.
> Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Not necessarily; the system might have a more up-to-date tzdata.
Generally you'd use --with-system-tzdata on a platform where you expect
to receive routine package updates for the tzdata files, independently
of the Postgres release cycle. It seems reasonable to assume that
anyone currently shipping tzdata is offering 64-bit files. (But we do
have that regression test check in there to make sure.)
regards, tom lane
On Oct 13, 2008, at 11:53, Tom Lane wrote: >> Oh. Is it not preferable to use the tzdata that ships with >> PostgreSQL? > > Not necessarily; the system might have a more up-to-date tzdata. Gotcha. > Generally you'd use --with-system-tzdata on a platform where you > expect > to receive routine package updates for the tzdata files, independently > of the Postgres release cycle. It seems reasonable to assume that > anyone currently shipping tzdata is offering 64-bit files. (But we do > have that regression test check in there to make sure.) Understood. Thanks for the explanation (and the regression test!). Best, David
Tom Lane napsal(a): > Generally you'd use --with-system-tzdata on a platform where you expect > to receive routine package updates for the tzdata files, independently > of the Postgres release cycle. It seems reasonable to assume that > anyone currently shipping tzdata is offering 64-bit files. (But we do > have that regression test check in there to make sure.) Unfortunately, you are not correct here :( see: http://bugs.opensolaris.org/view_bug.do?bug_id=4246033 Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
On Oct 13, 2008, at 12:35, Zdenek Kotala wrote: > Tom Lane napsal(a): > >> Generally you'd use --with-system-tzdata on a platform where you >> expect >> to receive routine package updates for the tzdata files, >> independently >> of the Postgres release cycle. It seems reasonable to assume that >> anyone currently shipping tzdata is offering 64-bit files. (But we >> do >> have that regression test check in there to make sure.) > > Unfortunately, you are not correct here :( see: > > http://bugs.opensolaris.org/view_bug.do?bug_id=4246033 So ideally all OS venders would ship 64-bit tzdata files, eh? Best, David