Manifested worries about the Y2K38 and Y2K40

LTV2008_mac said:

Hello, I don't post often in this forum, in fact, my last post was in 2024. Despite this, this is still an interesting thing to talk about.

Hello, as you may know, in year's time, (around 13-15 years) there will be time overflow errors in UNIX (2038) and HFS/HFS+ (2040), similar to the Y2K bug. This can potentially affect systems running Mac OS X.
Will old Mac hardware still work?
Will there be patches (software and hardware)?
Will there be better emulators in the future?

Sorry for the vague and potentially doomsday-ish question, i just wanted to ask.

Click to expand...

for 32-bit 68K Macs, they'll probably survive up to 2040, and I bet you future patches will make them work. For PowerPC, I imagine they can process years well after 2040, especially G3 and newer

LTV2008_mac said:

Will old Mac hardware still work?

Click to expand...

Yes. No problem. As commonly occurs, whenever the PRAM battery has died or is removed, the date goes to 1904. That's exactly what will happen when the clock rolls over in 2040. The Mac works just fine.

LTV2008_mac said:

Will there be patches (software and hardware)?

Click to expand...

Yes. A number of people have put considerable thought into the subject.

1. Improving the resolution of the date-time clock: easy. We just need to agree to a place in PRAM to store an additional high byte. The high byte can be incremented in roll-over detection software, or (better) set by new network time driver/hardware, or manually set by the user in a new or patched date/time control panel.

2. Allow new software to access the improved clock: easy. Add an option bit to an existing trap or add a gestalt call.

3. Allow old software to access the improved clock: difficult. Unfortunately, GetTime (which would be perfect as it is a record not a 32-bit integer) and even GetDateTime (which is a 32-bit integer) is glue code, not traps. They access the low-memory global directly. So, we can't just patch the traps. And, any software that stores time as a 32-bit integer in memory/disk is limited to a timespan. We can fake it on display by patching the Secs2Date trap, but would need to give up early dates to simulate newer dates.

We can replace things like SuperClock and Date/Time control panels with new software.

4. Storing improved dates on files and drives: difficult. We would need to agree on where to store the extra information (a separate repository? unused file info bytes in HFS? blow out the backed up date?) and figure out the right places to patch whenever a file changes.

5. Allow new software to access the improved dates on files and drives: easy. Add an option bit to an existing trap or add a gestalt call.

6. Allow old software to access the improved dates on files and drives: difficult. This is a real problem with StuffIt, BinHex, DiskDoubler, and Compact Pro, as their compressed file formats don't have room for the extra information. Tiny Transfer solves the BinHex problem (dates are stored in an ISO format). But StuffIt will strip the 'improved' year off anything you archive. Worse still, Finder will do so with every file that you copy. So, that will be extra difficult.

I think the solution is to take this a bite at a time.

First, solve 1 and 2.
Second, introduce a SuperClock and date/time control panel replacement. Add network time drivers to the fancy new scsi+wifi drives.
Third, introduce a new common open-format multi-file archive standard with ISO dates.
Then, the real work starts.

- David