From mboxrd@z Thu Jan  1 00:00:00 1970
From: random832@fastmail.com (Random832)
Date: Wed, 13 Dec 2017 10:07:56 -0500
Subject: [TUHS] Date madness
In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu>
Message-ID: <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com>

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