handling 64bit time_t's

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/