Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!ux1.cso.uiuc.edu!dino!hascall
From: hascall@cs.iastate.edu (John Hascall)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <2506@dino.cs.iastate.edu>
Date: 22 Aug 90 14:20:39 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com> <11187@alice.UUCP>
Sender: usenet@dino.cs.iastate.edu
Organization: Project Vincent, Iowa State University Computation Center
Lines: 23

In article <11187@alice.UUCP> andrew@alice.UUCP (Andrew Hume) writes:
}In article <26012@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes:
}> One of the nice things about using 64 bits for the time is that
}> you can then put it in nanoseconds - which you *almost* really
}> need on really fast machines. (100ns might be ok, but the
}> difference is still contained in 64 bits, so just do it!!)

}that VMS (i think) has some funny date like 1858 as its epoch, the so-called
}smithsonian time.

   VMS keeps time in 64 bits (really 63, negative times are "delta times"), 
   in 100 nSec units, since 17 Nov 1858 (when the calendar jumped 11 days?).

}   i also note that in the third edition of unix, when the time was measured
}in clock ticks (and thus wrapped around every 2.? yrs), ken proposed to deal
}with wraparound by changing the epoch in the manual and running a special
}fsck-like program that subtracted a year from every inode.

   Boy, this really loses today now that clocks tick faster than 60 HZ
(60 HZ = 828 days, 256 HZ = 194 days, 1000 HZ = 50 days).

John Hascall  /  Project Vincent  /  Iowa State University Comp Ctr
john@iastate.edu  /  hascall@atanasoff.cs.iastate.edu