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

Y2K2020 Date Problem System 7

frameworker2019

New member
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

Well-known member
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  ;) )

 
Last edited by a moderator:

Crutch

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

 

jessenator

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

 

jessenator

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

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

 

sfiera

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

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

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

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

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

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

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

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

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

LaPorta

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

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