Or the Earth. :undecided:
The clock uses a 32-bit number to keep track of the number of seconds from January 1, 1904. This runs out in February of 2040. After that, it will revert to 1904.Having no background, or rather detail, about how the control panel works, is 2042 a hardware limitation then? I'm assuming it it, otherwise one would think a further date would have been made the minimum...
:scrambled:AFS fixes the problem but, of course, that will only work on versions of Mac OS X that support AFS.
Given that the first Mac was 1984 and the first Apple was 1976, there's not going to be any Apple or Mac files or applications dated before 1972. So, that seems the best option. Downside is the sorting might be off for the reason you mention, though I'm not sure if that will cause any problems for anything the computers are going to be used for. That is, I don't think they'll be running airplane schedules or anything. I would think primarily games and word processing. And, for me, if I create a file on July 30, 2042, if that shows up as July 30, 2042 (and I can move it to a then-modern computer and preserve that date), that works for me.You could move it half the range forward, to 1972–2108. Dates from 1972–2040 would be preserved, but you’d lose dates before 1972 (probably fine) and some software would think 2040–2108 < 1972–2040.
I’ve given this some thought actually. This could be done. One would have to patch the OS traps _Date2Secs and _Secs2Date (which convert the real-time clock result, which is a long containing seconds since 1904, into a date/time record and back) and the International Utilities routines in _Pack6, IUDateString, IUTimeString, IUDatePString, and IUTimePString (which turn the raw long into formatted strings with appropriate localization). This would be easy, and should work for all Mac software that is “old enough” (other ways to deal with date/times may have arisen after the System 7 era, I would need to check). The caveats would be:I’d say it’s still mostly a software issue, just one with more difficult tradeoffs. A 32-bit number of seconds can only represent a range of 136.1 years, but while those 32-bit numbers may exist in a lot of places (filesystem, protocols, PRAM) their interpretation is up to software.
It might be possible to write an extension that patches Apple’s date utilities to assign a different 136.1-year range to those bits than 1904–2040:
- You could move it half the range forward, to 1972–2108. Dates from 1972–2040 would be preserved, but you’d lose dates before 1972 (probably fine) and some software would think 2040–2108 < 1972–2040.
- You could shift it 100 years, to 2004–2140, and trust users to recognize that classic software from “2084” is really from 1984. But, correct dates get difficult from 2100; the advantage of 1904–2040 is that there’s no need to implement the century rule of leap years, but starting 2100 that’s necessary.
Now that’s my idea of a fun weekend.I may try this one weekend, just to see if it works and be really realllllly well prepared ....