Classic Mac OS will survive Y2038 (and maybe longer)

Indeed. Most of us won't be there most likely (but who knows?), so it will be someone else's problem... unless someone wants to fix it now, in a time where there's still a few people around who actually know how.

c
Well then, I should probably learn how. Just to carry on.

 
The UNIX epoch problem has already been a problem and solved in many systems. The end date for 30 year mortgages for instance......

 
  • if they would be able to extend the year why not make it to 9999 and when thats over (hopefully if humanity doesn't keel over somehow) and then have it loop back to 1
 
I wonder how long before Y2k38 people will get on board with checking compliance on embedded systems, etc... I'm guessing 2-3 years.
Digging up an old thread I know (I was looking for the 2020 patches, which by the way are here and here) but this caught my eye.
Can't say too much about my job, but for an embedded system I have been part of the development of, we fully designed and tested it to function correctly post 2040 and beyond. Needless to say it doesn't run Windows or Linux(!)

The two dates we needed to worry about were 2036 (for NTP GPS clock rollover) and 2038 (for the Unix epoch). Interestingly a lot of GPS clocks sold today can't deal with post 2036 dates yet, and indeed some versions of Linux still don't support post 2036 NTP servers. I can assure you that FreeBSD does, however.
 
After some investigation I believe beyond-2040 is challenging but feasible. I've been a Mac user since the black and white days and I continue to have a great fondness for the System 7 era, lurking here to read with some satisfaction the clever hacks people have come up with for those machines. It has been years since I had the quality time or cognitive space for a significant hobby project, but between the patches linked above, better emulators, and advances in tool-assisted reverse engineering I suspect I may now be able to implement the toolbox routine and HFS patches necessary to help at least the core system last long into the future. If successful and feeling ambitious I would also hope to investigate an updated IP stack (likely glue around lwIP), updated cache/VM infrastructure incorporating knowledge gained in the 30+ years since those subsystems were written, mixed mode support (for early PPC), and more.

Are there volunteers here who would be interested in helping test these patches on their hardware?
 
I've been thinking about this, and in my opinion the "general case" solution would have to be something like what Apple had to do when moving beyond 4GiB disk volumes: Implement a larger data structure that can handle wider values (say, 48 or 64 bits); implement a Gestalt selector to indicate its availability; and define the behaviour of the old-style (i.e., current 32-bit) interface when the new one is in use – under both the "not overflowed yet" and "post-2040" conditions.
 
The only complicating factor would be whether ot not any larger data structures are defined to incorporate a 32-bit date. You'd have to track down and redefine ALL of them as part of the first item on that list I just gave.
 
Back
Top