Y2K2020 Date Problem System 7

[frameworker2019]

Hi folks,

after a long time I've started my Classic II and I was totally surprised that I cannot set a date behind 31.12.2019.

There must be a trick to circumvent it, isn't it??????

 

[jessenator]

Yeah, with most Macs it's a System Software limitation, but the homebrew control panel called SetDate on this page should allow you to set a proper 2020 date: http://www.synack.net/~bbraun/macapps.html

Mac OS 9.0+ I believe corrected that in system, but that's not really an option for the Classic II (nor would I recommend it if it was  )

 

[Crutch]

I feel like there should be a pinned thread about this now.  It’s going to keep coming up forever!

 

[jessenator]

What's odd is that I did a search and not much came up for it, but I know there have been at least 3 threads about this since quarantine... I was going to link to one of those posts, but I could not for the life of me find it... like even the slightly older one that I posted in and how I couldn't get my PowerComputing machines to reset the date, lol. 

 

[frameworker2019]

Thank you guys, but what about after 2042 ??

I might still be on earth then

 

[Dog Cow]

Thank you guys, but what about after 2042 ??

I might still be on earth then

But your old Macs might not!!

 

[dcr]

Thank you guys, but what about after 2042 ??

I might still be on earth then

But your old Macs might not!!

Or the Earth.  :undecided:

On the plus side, maybe time travel will have been invented before 2042.  Then, you can go back well before 2042 and not need to worry about the clock again.  Also, NOS will be replaced with NNS.

 

[jessenator]

Having no background, or rather detail, about how the control panel works, is 2042 a hardware limitation then? I'm assuming it it, otherwise one would think a further date would have been made the minimum...

 

[dcr]

Having no background, or rather detail, about how the control panel works, is 2042 a hardware limitation then? I'm assuming it it, otherwise one would think a further date would have been made the minimum...

The clock uses a 32-bit number to keep track of the number of seconds from January 1, 1904.  This runs out in February of 2040.  After that, it will revert to 1904.

It affects the HFS and HFS+ file systems too.

AFS fixes the problem but, of course, that will only work on versions of Mac OS X that support AFS.

 

[jessenator]

AFS fixes the problem but, of course, that will only work on versions of Mac OS X that support AFS.

:scrambled:

I thought about using something like this: https://www.timeanddate.com/calendar/repeating.html?year=2040 to reset once it runs out, but horology is not my strong suit.

 

[sfiera]

I’d say it’s still mostly a software issue, just one with more difficult tradeoffs. A 32-bit number of seconds can only represent a range of 136.1 years, but while those 32-bit numbers may exist in a lot of places (filesystem, protocols, PRAM) their interpretation is up to software.

It might be possible to write an extension that patches Apple’s date utilities to assign a different 136.1-year range to those bits than 1904–2040:

• You could move it half the range forward, to 1972–2108. Dates from 1972–2040 would be preserved, but you’d lose dates before 1972 (probably fine) and some software would think 2040–2108 < 1972–2040.
  
• You could shift it 100 years, to 2004–2140, and trust users to recognize that classic software from “2084” is really from 1984. But, correct dates get difficult from 2100; the advantage of 1904–2040 is that there’s no need to implement the century rule of leap years, but starting 2100 that’s necessary.
  

The real fix is 64-bit timestamps, which give you a half-trillion years to work with at 1-second precision, but you can’t fit that in the existing slots for timestamps, and you need to get software to change, and agree how to find it the new numbers, which is not an easy task at this point.

 

[dcr]

You could move it half the range forward, to 1972–2108. Dates from 1972–2040 would be preserved, but you’d lose dates before 1972 (probably fine) and some software would think 2040–2108 < 1972–2040.

Given that the first Mac was 1984 and the first Apple was 1976, there's not going to be any Apple or Mac files or applications dated before 1972.  So, that seems the best option.  Downside is the sorting might be off for the reason you mention, though I'm not sure if that will cause any problems for anything the computers are going to be used for.  That is, I don't think they'll be running airplane schedules or anything.  I would think primarily games and word processing.  And, for me, if I create a file on July 30, 2042, if that shows up as July 30, 2042 (and I can move it to a then-modern computer and preserve that date), that works for me.

I would imagine, though, in the case where the clock battery is dead, the system might default to January 1, 2041 instead of January 1, 1904?  (Or February 6, 2040?)  Not a major problem but just a change to get used to.

 

[sfiera]

I think so. What would happen when moving the file to a modern computer would depend on how you moved it—if via AFP, the receiving software would need to agree on the interpretation of timestamps.

The other scheme that’s worth considering is one with variable precision, where you halve the resolution of the timestamp every 68 years instead of wrapping around. By the 2700s, you’d only have hour-resolution timestamps, but hey, better than a hard limit like 2040 (or 2108).

 

[sfiera]

I’m probably speculating too much here. I certainly don’t have the knowledge or skills to make this happen now. But hey, 20 years to prepare, right? What could go wrong?

 

[Crutch]

I’d say it’s still mostly a software issue, just one with more difficult tradeoffs. A 32-bit number of seconds can only represent a range of 136.1 years, but while those 32-bit numbers may exist in a lot of places (filesystem, protocols, PRAM) their interpretation is up to software.

It might be possible to write an extension that patches Apple’s date utilities to assign a different 136.1-year range to those bits than 1904–2040:

• You could move it half the range forward, to 1972–2108. Dates from 1972–2040 would be preserved, but you’d lose dates before 1972 (probably fine) and some software would think 2040–2108 < 1972–2040.
  
• You could shift it 100 years, to 2004–2140, and trust users to recognize that classic software from “2084” is really from 1984. But, correct dates get difficult from 2100; the advantage of 1904–2040 is that there’s no need to implement the century rule of leap years, but starting 2100 that’s necessary.
  

I’ve given this some thought actually.  This could be done.  One would have to patch the OS traps _Date2Secs and _Secs2Date (which convert the real-time clock result, which is a long containing seconds since 1904, into a date/time record and back) and the International Utilities routines in _Pack6, IUDateString, IUTimeString, IUDatePString, and IUTimePString (which turn the raw long into formatted strings with appropriate localization).  This would be easy, and should work for all Mac software that is “old enough” (other ways to deal with date/times may have arisen after the System 7 era, I would need to check).  The caveats would be:

1.  Sort order will almost certainly be broken; most vintage Mac software will likely sort by the bare long value without interpreting it first

2.  The semantics of the raw date time as seconds-since-1904 was documented and never indicated as something that might ever change, so some programs probably just assume that’s how it works and interpret the value themselves (despite the existence of a perfectly good _Secs2Date trap).  Those programs will misinterpret post-2040 dates.

3.  Moving files with these reinterpreted dates to any machine lacking the patch will show the wrong dates.  This would certainly include any modern machines that expect to see a normal, vintage MacOS-style date time.

I may try this one weekend, just to see if it works and be really realllllly well prepared ....

 

[sfiera]

I may try this one weekend, just to see if it works and be really realllllly well prepared ....

Now that’s my idea of a fun weekend.

I dug a little more: there has been a 64-bit LongSecs2Date in Script Manager at least System 6 (per Technote TE09). It would need an analogous patch, though if Apple was already preparing for 2040 in the 80’s, it would be nice if they’d finished the job!

 

[Crutch]

Thanks, I noticed that too last night.  I had forgotten about that.  It’s documented (not very well) in IM volume 6.  I wonder if anyone actually used it?

 

[jessenator]

I'll also update here, with the post that might've been lost.

As an alternative to SetDate, there's a 2020 Patch: a simple system extension that allows you to set the date with the Date & Time control panel!

Vintage Mac 2020 fixes

I've had issues in the past with some Macs and clones (mostly clones), but this extension does the trick.

 

[LaPorta]

Here is a question: what happens to those files that were created on Macs with PRAM batteries no one cared about and they all have created dates of 1904?

 

[jessenator]

I think there was some utility that would programmatically go through and correct them, but for the life of me, I cannot remember what it was called...

Does TechTool Pro do that?