Jump to content
frameworker2019

Y2K2020 Date Problem System 7

Recommended Posts

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 ;))

Edited by jessenator

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
22 hours ago, frameworker2019 said:

Thank you guys, but what about after 2042 ??

I might still be on earth then :-)

But your old Macs might not!! :-P

Share this post


Link to post
Share on other sites
8 hours ago, Dog Cow said:
22 hours ago, frameworker2019 said:

Thank you guys, but what about after 2042 ??

I might still be on earth then :-)

But your old Macs might not!! :-P

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
8 hours ago, jessenator said:

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
8 hours ago, sfiera said:

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
11 hours ago, sfiera said:

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 .... :)

 

 

 

 

Share this post


Link to post
Share on other sites
12 hours ago, Crutch said:

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×