Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!ux.acs!vw.acs.umn.edu!dhoyt
From: dhoyt@vw.acs.umn.edu
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <2044@ux.acs.umn.edu>
Date: 10 Aug 90 17:09:06 GMT
Sender: news@ux.acs.umn.edu
Organization: University of Minnesota, Academic Computing Services
Lines: 15

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!!)

Actually you will still want to quantities: date and time.  A date, measured in
milliseconds or microseconds to handle dates and universal time.  That would
handle most people, with the execption of the bang/wimper types.  You would
also want an interval time.  This ideally would be in sub-picosecond units,
perhaps as a distance, even in this day and age. That would allow your OS to
run (and report) the testing equitment for new ssd's, particle accelerators, 50
meter dashes and other transient experiments in a consistant, even manner.

david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet