Thread: big int

big int

From
newsreader@mediaone.net
Date:
This isn't exactly related to pg but
I thought some wise person might be able
to explain.

i've been storing the number of seconds
since  Dec 31 19:00:00 1969 whenever
I have to store a time format. For this
integer type is good.

As we all know come year 2032 or so this
number will exceed the range of integer.

If I want to prevent problems in the future
should I use int8.  Is there significant
overhead?  It seems that on an DEC/alpha
64 bit platform perl does not seems
to be aware that it's not on a 32 bit platform.
--------------
% perl -MTime::Local -e 'print timelocal(9,9,9,9,9,200)' ;
Can't handle date (9, 9, 9, 9, 9, 200) at -e line 1
--------------

Thanks


Re: big int

From
"Richard Huxton"
Date:
From: <newsreader@mediaone.net>

> This isn't exactly related to pg but
> I thought some wise person might be able
> to explain.

Sorry - you got me instead ;-)

> i've been storing the number of seconds
> since  Dec 31 19:00:00 1969 whenever
> I have to store a time format. For this
> integer type is good.

I'd suggest "timestamp" for PG - handles big dates just fine.

> As we all know come year 2032 or so this
> number will exceed the range of integer.

Ssh - the 2038 crisis is bankrolling my retirement fund.

> If I want to prevent problems in the future
> should I use int8.  Is there significant
> overhead?  It seems that on an DEC/alpha
> 64 bit platform perl does not seems
> to be aware that it's not on a 32 bit platform.
> --------------
> % perl -MTime::Local -e 'print timelocal(9,9,9,9,9,200)' ;
> Can't handle date (9, 9, 9, 9, 9, 200) at -e line 1
> --------------

Odd - I get -1 returned (as per the docs) on Intel.

This particular feature is probably an artifact of implementation. I'd guess
the internal code gets integers translated as int4 because that's what it is
for most people.

Actually I think I'm talking rubbish - looking at the code for
Time::Local.pm you might be getting this error _because_ you are on a 64-bit
platform. Take a look at "sub cheat" (I _think_ line 114 might be the
problem).

For big date handling, I've always quite liked string representations.
Unfortunately, no good for calculations. If you can't find a Time::Big
module on CPAN I'd recommend checking out the perl.moderated newsgroup -
there are big guns there who know what they're talking about.

- Richard Huxton