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@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