Lists: | pgsql-hackers |
---|
From: | Adrian Gartland <ade(at)oregan(dot)net> |
---|---|
To: | hackers(at)postgreSQL(dot)org |
Subject: | handling 64bit time_t's |
Date: | 1999-01-25 19:48:23 |
Message-ID: | Pine.LNX.4.04.9901251924220.16460-100000@wilf.oregan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
I've been looking at fixing the the timestamp problem on the alpha.
I can get it working but I'm wondering if there is any particular
reason that postgres is currently being limited to 2038 as being
the top year.
define UTIME_MAXYEAR (2038)
As you probably know....time_t (a long) on the alpha is a 64 bit
value, so it can cope with dates waaaaaay into the future.
The problem currently breaking the timestamps on the alpha boils
down to
#define AbsoluteTimeIsReal(time) \
((bool) (((AbsoluteTime) time) < NOEND_ABSTIME && \
((AbsoluteTime) time) > NOSTART_ABSTIME))
returning false cause "time" after being propriately cast around
is always returning a value < NOSTART_ABSTIME which
was defined as
#define NOSTART_ABSTIME ((AbsoluteTime) 0x80000001)
I changed AbosoluteTime to be a time_t instead of a int32...
which I'm wondering whether this is a good idea now.
The long an short of it...
I can get it working..changing a number of stuff to time_ts from
int32...this has no effect on any 32bit machines as they are the
same bitsize.
I can get it working (well..i think it was working) so that epoch=0
infinity=infinty 'now' is the time of the transaction.
or
Have a nightmare of a time trying to workout how to extend the available
time-range. I have tried that...and it all seems to be working bar I
cannot get >2038 due to other code in the proggy.
Umm...comments?
Ta.
--
Adrian Gartland - Server Development Manager
Oregan Networks UK Ltd Tel: +44 (0) 1530 56 33 11
Huntingdon Court, Ashby de la Zouch Fax: +44 (0) 1530 56 33 22
Leicestershire, LE65 1AH, United Kingdom WWW: http://www.oregan.net/
From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Adrian Gartland <ade(at)oregan(dot)net> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] handling 64bit time_t's |
Date: | 1999-01-26 03:09:43 |
Message-ID: | 36AD31F7.3B2FE98E@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
> I've been looking at fixing the the timestamp problem on the alpha.
> I can get it working but I'm wondering if there is any particular
> reason that postgres is currently being limited to 2038 as being
> the top year.
> define UTIME_MAXYEAR (2038)
> As you probably know....time_t (a long) on the alpha is a 64 bit
> value, so it can cope with dates waaaaaay into the future.
> The problem currently breaking the timestamps on the alpha boils
> down to
> #define AbsoluteTimeIsReal(time) \
> ((bool) (((AbsoluteTime) time) < NOEND_ABSTIME && \
> ((AbsoluteTime) time) > NOSTART_ABSTIME))
>
> returning false cause "time" after being propriately cast around
> is always returning a value < NOSTART_ABSTIME which
> was defined as
> #define NOSTART_ABSTIME ((AbsoluteTime) 0x80000001)
> I changed AbosoluteTime to be a time_t instead of a int32...
> which I'm wondering whether this is a good idea now.
I'm a bit slow. If the Alpha's time is read back as signed 8 bytes, but
is then coerced to AbsoluteTime as signed 4 bytes, then why would this
comparison fail? Though if things aren't 4 bytes at this stage and the
0x80000001 is a large positive integer in 2038 then the comparison fails
as you say.
> The long an short of it...
> I can get it working..changing a number of stuff to time_ts from
> int32...this has no effect on any 32bit machines as they are the
> same bitsize.
> I can get it working (well..i think it was working) so that epoch=0
> infinity=infinty 'now' is the time of the transaction.
> or
> Have a nightmare of a time trying to workout how to extend the
> available time-range. I have tried that...and it all seems to be
> working bar I cannot get >2038 due to other code in the proggy.
The problem is that abstime is stored in all of the database tables in
some system fields, specifically as 4 bytes (the length is defined in
pg_type). I'm not sure how to make something this fundamental have a
platform-specific length.
My solution (at least for now) would be to make sure it becomes a 4 byte
quantity just after the call to time() and before calls to localtime().
Look for all instances in src/backend/utils/adt/*.c. Not sure at the
moment what else might need looking at.
- Tom