Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!uunet!in3.uu.net!128.138.240.25!boulder!rintintin.Colorado.EDU!fcrary
From: fcrary@rintintin.Colorado.EDU (Frank Crary)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Year 2000 problem?
Date: 1 May 1997 01:07:06 GMT
Organization: University of Colorado, Boulder
Lines: 24
Message-ID: <5k8qbq$j2u@lace.colorado.edu>
References: <3365F634.794BDF32@jnet.vi> <01bc54d3$9d98ca00$6601a8c0@teds.portsoft.com> <5k66ro$r9l@lace.colorado.edu> <E9GGp7.1w3@midway.uchicago.edu>
NNTP-Posting-Host: rintintin.colorado.edu
NNTP-Posting-User: fcrary
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:40057
In article <E9GGp7.1w3@midway.uchicago.edu>,
Eric Fischer <eric@fudge.uchicago.edu> wrote:
>> Typically it's a 32-bit integer, but that's not a requirement of Unix
>> operating systems (the machines Unix was written on back in 1972 certainly
>> didn't use 32-bit integers...) Given how quickly technology is improving,
>> any one who is still using 32-bit bit registers in 2032 would deserve
>> what they get.
>Sixth Edition Unix and earlier represented the time as an array of two
>16-bit integers. This was represented in memory identically to the
>32-bit integer that started being used for time when the "long" type
>was added to the C compiler. This, by the way, is why time() takes a
>pointer argument -- it wasn't possible at the time to have a 32-bit
>return value from a function.
Fair enough. But I think my basic point is correct: UNIX is fairly
flexible about how the system time is stored. If you can use two
16 bit integers instead of one 32 bit integer, I really doubt that
you'd have trouble using a 64 bit integer. So there won't be a problem
in 2032, since people will, almost certainly, be using 64 bit registers
by then.
Frank Crary
CU Boulder