Subject: Re: Problems with current (1.6X) on vax?
To: NetBSD/vax Discussion List <port-vax@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: port-vax
Date: 09/03/2003 15:38:06
[ On Wednesday, September 3, 2003 at 14:55:03 (-0400), John Klos wrote: ]
> Subject: Re: Problems with current (1.6X) on vax?
>
> Oh, someone will make it unsigned (there never was much of a use for
> negative time) if not made 64 bit.

It's also good to be able to use a "local" epoch instead of picking one
arbitrarily long before the start of human (or even "solar") history,
and negative offsets work quite well for this purpose.

So negative time can be useful, but with current APIs it is important to
have a non-zero value that's considered to be invalid.  While "-1" alone
will suffice to stand in for the invalid value, even on a VAX, the
problem is of course too many programmers use relative tests instead of
absolute tests.  We'll have to throw the whole API out and start fresh
to really prevent that problem.

> Unsigned will give us another 68 years;

Oops, yes of course, 'date' automatically trims the command-line value
into a 31-bit value without complaining.  For some reason I didn't even
think twice when I typed 2^32 and still ended up with 2038:

	$ TZ=GMT0 date -r $(echo '2^32 - 1' | bc)
	Tue Jan 19 03:14:07 GMT 2038
	$ TZ=GMT0 date -r $(echo '2^31 - 1' | bc) 
	Tue Jan 19 03:14:07 GMT 2038
	$ TZ=GMT0 date -r $(echo '2^64 - 1' | bc) 
	Tue Jan 19 03:14:07 GMT 2038

> 64 bits will give us a calendar which could include the beginning and the
> end of the universe (292 billion years in each direction).

One full second for timestamps even on files is beginning to be a
limiting factor for certain things.  What we really need first is more
resolution and that pretty much implies going to at least a signed
64-bit value to stay where we are, epoch-wise.  Of course even with
microsecond resolution a signed 64-bit time_t does us quite well into
the future even if we leave 0 at the current Unix epoch.  Even
nanosecond resolution with signed 64-bit values takes us long past the
time when current computing technology and all records and data it will
ever produce will likely be so antiquated as to be less than irrelevant.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>