• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

System 1-5 Patch for >2020 Date

loplop

Well-known member
For pre-System 6, does anyone have a patched Alarm Clock DA that allows the date to be set >2020? Would appreciate a copy if so.
 

loplop

Well-known member
I found a solution—Macintosh Garden had a piece of software called “PRAM-5.0” which allows setting of PRAM values, including the date/time:
FC9FC86F-06B7-4F90-AAA9-71970D797DFA.jpeg
 

dcr

Well-known member
Someone remind me to check back on this thread in 18 years...
I'll be curious how some of the patches work. Like if they "patch" it to read the base code as the new years, such that what the old Mac OS originally saw as 1904 would now be seen as 2041, what happens when you exchange a file with a newer computer? Will it see the file date as 2041 or 1904?
 

Crutch

Well-known member
I think part of the idea was that Apple wanted applications that use the standard date/time routines to be able to work reasonably far into the “recent past”. It wasn’t about supporting retroactive file creation dates obviously. But someone using Multiplan in 1984 likely wanted to be able to enter quarterly sales data or whatever going back to 1981 or 1978 or …. So starting in 1980 was probably not a great idea. Then the question was just how far back should the date system go? Certainly Apple (rightly) suspected major system upgrades would arrive well before the 1904-based system ran out of years, so it seems like it wasn’t a bad call.

I'll be curious how some of the patches work. Like if they "patch" it to read the base code as the new years, such that what the old Mac OS originally saw as 1904 would now be seen as 2041, what happens when you exchange a file with a newer computer? Will it see the file date as 2041 or 1904?

I’ve played around with writing a patch for this. My approach was to patch _Secs2Date to reinterpret date-time records stored as seconds to return a different calendar year for display purposes (reinterpreting, for example, 1904-1964 as 2040-2100, but leaving dates in 1965+ alone). From Googling “Macintosh Secs2Date” it looks like multiple others have tried this same approach. It works, but the side effect would be that any (for example) 2040 dates would appear as 1904 on a system not running the patch (which I guess, too bad, run the patch!), and anyone sorting dates based on direct binary values will think that 2040 comes before (say) 2020, which might be a more serious shortcoming but is unavoidable without totally breaking backward compatibility by reinterpreting the full range of binary values.
 
Top