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: