System 1-5 Patch for >2020 Date
- Thread starter loplop
- Start date
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?
https://lowendmac.com/lab/04/0115.html - it was convenient.Why, oh why, did Apple choose 1904 to start counting up from
I have read that—but it still doesn’t answer: why did the Macintosh team feel an accurate calendar back to 1904 was important? Certainly there would never be files brought on to a Mac from 1904. Or even 1964…
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’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.
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.
