🚀 go-pugleaf

From: campbell%maynard.UUCP@HARVISR.HARVARD.EDU (Larry Campbell)
Date: Fri, 5 Sep 86 01:51:09 EDT
Organization: The Boston Software Works, Inc.

>From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao)
>
>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
> ...
>(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
>tried this on the s5/VAX.)

For what it's worth, I tried several interesting values on my VENIX 2.0
(V7-based) system.  It handles negative values "properly" (that is, it
prints reasonable dates prior to 1970);  for instance, 0xC0000000 yields
"1935 Dec 23 05:22:56".  And it also handles dates beyond 2000 correctly;
0x70000000 yields "2029 Jul 18 01:49:52".
-- 
Larry Campbell                             The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     (617) 367-6846

[ Depends on what you call broken.

Another example where time values outside the currently supported
(or proposed) range would be useful:  some of us like to play with
genealogical software;  I have known ancestors back to the thirteenth
century and frequently work with data to the sixteenth century.
But time_t probably isn't the appropriate format to keep such dates,
considering Julian vs. Gregorian calendars, old and new style new years,
etc.  -mod ]

Volume-Number: Volume 6, Number 44