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

Classic Mac OS will survive Y2038 (and maybe longer)

MacintoshMan1999

Well-known member
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.

 

NJRoadfan

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

 

snes1423

Well-known member
  • 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
 

aladds

Well-known member
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.
 
Top