Manifested worries about the Y2K38 and Y2K40

[LTV2008_mac]

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.

 

[Nixontheknight]

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.

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

 

[JDW]

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.

It is a very important topic, and as such, I would encourage you to post in the forum more because you are helping us to think about these matters.

What's interesting is that some people working the problem say things like: "I am not sure that anybody will use HFS/HFS+ after 2040." Which of course totally and utterly ignores the vintage Mac hobby community.

@David Cook talks about "brave souls trying to fix the 2040 issue" here.
And the reason for that word "brave" becomes clear when you read what David says here:

Y2K2020 Date Problem System 7

I think there was some utility that would programmatically go through and correct them, but for the life of me, I cannot remember what it was called... Does TechTool Pro do that? I know Norton Utilities does, it complains about bad dates and fixes them.

68kmla.org

I guess no one will be incentivized to fix the problem until faced with it in 2040. Or will we turn to AI for that?

 

[David Cook]

Will old Mac hardware still work?

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.

Will there be patches (software and hardware)?

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

 

[JDW]

David, thanks for the detailed explanation!

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

We know that if you pull the PRAM battery, not only will the Date/Time be wrong, but your Mouse defaults to painfully slow tracking (perhaps the most excruciating thing about a missing PRAM battery), and various General Control Panel settings get reset (cursor blinking rate, etc.), speaker volume drops too low, and 32-bit addressing gets switched to 24-bit addressing (on some machines). There are a few other things as well. It's a hassle to deal with that, which is why the RTC replacement chips that came out in the last year (which have onboard memory) are really neat. You can leave out a PRAM battery completely, but because everything is backed up inside that RTC replacement chip, the only thing that isn't perfect is the date/time the next time you power ON, which is a small sacrifice to be PRAM battery free. (Another reason I leave my PRAM battery out is because those RTC replacement chips pull about 1mA of current continually, which will drain a PRAM battery much too quickly.)

But the 2040 problem is a little mysterious. As you said, the hardware will function, but if a user of an old Mac does absolutely nothing (no patches... nothing), what are all the negatives that will happen when we reach the year 2040? All the file dates from 2040 forward will simply be wrong (become 1904?), and that's about it? Or are there other more sinister problems triggered by 2040?