🚀 go-pugleaf

From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao)
Date: Tue, 2 Sep 86 04:14:29 edt
Organization: Hadron, Inc., Fairfax, VA

In article <5638@ut-sally.UUCP> you write:
>From: elsie!ado@seismo.UUCP 
>While it's true that no UNIX files date back to before January 1, 1970,
>there *are* uses for times before that epoch:  in personnel data bases where
>birth dates are recorded; in data bases recording astronomical events;
>in stock market price data bases (as used by chartist fanatics); and elsewhere.

These should be recorded in the DATE format of your DBMS, not as a
longint!  If your DBMS has no DATE format (tsk!), it should be recorded
as three [or six] ints.  Yes, I know you'll have to compare via a
procedure instead of an op; see the (tsk!) above.

>(And what of all those old 7094 executables that are being used on IBM machines
>running UNIX or a cousin?  :-))

What of them?

>I see more use in the short run for being able to record times between
>1901 and 1970 that I see for being able to record times after 2038.

Possibly.  But I plan to be living (and making plans) well into the
2000's.  I don't want to run up against a wall.  (I already have, in
that versions of Unix today don't allow such dates, and I have -- I
don't remember why! -- tried to use them.)

In addition, you would not be "retaining" any capability -- the systems
I know tend to turn negative dates into something on the order of:
	Sat Feb  5 01:28:16 2^A06
(This is -(60*60*24): the '^A' is, yes, a control-A.)
Any date after 31 Dec 1999 up to some value >> 2^31 loses everything
after the '2' in the year:  I think the second char of the year is
being converted to a control-@, or NUL character.

(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
tried this on the s5/VAX.)
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

Volume-Number: Volume 6, Number 43