[TUHS] Date madness

[jsteve@superglobalmegacorp.com (Jason Stevens)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106.  If you have source it’s incredibly trivial to change, and nothing changes size wise.

I did 4.3BSD a long while back, and the only thing I really changed was the date command so I could enter 4 year dates, otherwise everything seemed to run fine in the year 2040.

Sent from Mail for Windows 10

From: Random832
Sent: Wednesday, 13 December 2017 11:08 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Date madness

Seeing this thread (and in particular the "no long" versions of the date
code) got me thinking, how could the 2038 problem be solved for classic
unix?

Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get
to Y10K and is coincidentally as far as my ad-hoc implementation of
dividing by 86400 got) structure? How to encode times within 32-bit
fields on filesystems and such? Is it even worth it to do a fully
general implementation rather than simply treating it as unsigned,
delaying the problem until 2106?

And, for that matter, would a full implementation of modern time zone
data code (2.11BSD has one from a while back, though only supporting
32-bit times) be too large for smaller 16-bit unix systems?

On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote:
> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
> 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
> the
> date code is probably missing the '400 year' exception.
> 
> 	Noel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171214/eaec3545/attachment.html>