On Thu, 29 Oct 1998, Allen Briggs wrote:

> > Of course it mentions nothing about being Y2039 compliant.. but that's 
> > waaaay off.
> ...and much more painful to fix on most *nix systems.  One solution, of
> course, is to change time_t to be 63 bits instead of 31 (it's signed), but
> that has some non-trivial ramifications (time_t is stored in on-disk data
> structures in the filesystem and elsewhere.

but just think: it'll then be compliant up to the year 292271025015!
(ie kind of Y3e11 compliant.)

Just having a quick search around the web, it seems that Linux has
already started to make provision for 64 bit times in its inodes[4];
DEC Unix (with 64bit time_t) apparently has upgrade problems[2].
And, even though HP/UX has a 64bit time_t, it's getdate() can only
take a max year of 9999![3]

but hey.. if people can handle a complete uproot now with only 1 year to go,
I'm sure it'll be just the same in 2030's.

d

[1] http://catless.ncl.ac.uk/Risks/19.36.html#subj12.3
[2] http://archive.redhat.com/redhat-devel-list/1998-January/0088.html
[3] http://www.software.hp.com/STK/man/11.00/getdate_3c.html
[4] http://www.geog.ubc.ca/s_linux/sparclinux-1995/msg00397.html
-- 
David Leonard                           David.Leonard@csee.uq.edu.au
Dept of Comp. Sci. and Elec. Engg   _   Ph:+61 7 3207 5332 (AH)
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401