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.

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

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. Click to expand...

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:


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? :)

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

David, thanks for the detailed explanation!

>> David Cook said:

...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. Click to expand...

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?

>> JDW said:

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? Click to expand...

Having run quite a few Macs with dead/missing PRAM batteries, the main problem that I can see is that some software refuses to run (or glitches out) if the date isn't within a certain range. This is already happening right now, even on Macs with the correct 2025 date set in PRAM. I recently used some original PowerPrint install disks and the installer threw an error and failed to complete unless the date was set to sometime in the 1990s. However, I don't think that will be a serious problem since it's easy enough to use a control panel to set the date to what a given program wants to see.

However, since I'm not really familiar with the date/time subsystems David was talking about, it's possible there might be some other unexpected effects as well. Given the fact that every (working) classic Mac I've ever seen has worked just fine with an improperly set clock, though, I would expect those problems to be edge cases and very unlikely to affect the way most of us use our classic machines.

>> gopherman said:

...I don't think that will be a serious problem ... Click to expand...

What's really interesting about this is that we all could simply change our date to 2040 today and see what happens.

Full disclosure, even I haven't done that yet. :)

A potential answer hiding in plain sight! :D (I haven't actually tried it either.)

FWIW, at least AppleShare isn't going to have a problem with this. Unlike with the Mac, the designers of Apple Filing Protocol set the epoch to midnight on 1-1-2000. File sharing was using negative values (the value is a 32bit signed integer) back in the 90s! Note this would need to be taken into consideration with any post 2040 patch as the client does the math to calculate the offset with the server!