Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!andrew
From: andrew@alice.UUCP (Andrew Hume)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Summary: well, nearly...
Message-ID: <11187@alice.UUCP>
Date: 15 Aug 90 05:13:03 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 20

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


	this is nearly true. it is clear that support for high resolution time
is needed and a quanta around 1-10ns is about right. however, the problem is
that all the work around ISO (and there is a LOT of it) on date/time formats
varies considerably on the number of bits required but is tending towards
128 bits (high resolution + all dates (including BC)). i note in passing
that VMS (i think) has some funny date like 1858 as its epoch, the so-called
smithsonian time.
	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.