• 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

techknight

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?

I know Norton Utilities does, it complains about bad dates and fixes them.
 

David Cook

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

The System 9.2 Date & Time control panel rolls over in 2040 -- I just tried it. So, it does not appear to be fixed in the classic operating systems.
 

LaPorta

Well-known member
You need the since-written 2020 Patch extension:


This will not, however, fix the 2042 issue, that is entirely different.
 

bigmessowires

Well-known member
It sounds funny to be worrying about a 2040 or 2042 date problem, but the worries about 2020 and 2000 problems also sounded silly 20-40 years ago. If 68kMLA is still around in 2040, then we can look back on this thread and chuckle. Who's taking bets on the average selling price of a working SE/30 system in the year 2040?
 

Phipli

Well-known member
It sounds funny to be worrying about a 2040 or 2042 date problem, but the worries about 2020 and 2000 problems also sounded silly 20-40 years ago. If 68kMLA is still around in 2040, then we can look back on this thread and chuckle. Who's taking bets on the average selling price of a working SE/30 system in the year 2040?
Once we get there, patching the OS to read 1940 as 2040 might be an answer.

I'm planning on still having some 68k macs then, although I should probably thin out the collection some day.
 

David Cook

Well-known member
It sounds funny to be worrying about a 2040 or 2042 date problem, but the worries about 2020 and 2000 problems also sounded silly 20-40 years ago

I've put a lot of thought into this. Here are the layers:

1. Clock itself
2. System calls (i.e. GetDateTime)
3. File and directory creation/modification/backup date and time stamps
4. Finder and Date&Time control panel
5. Other applications (particularly Stuffit)

That is, the System calls need the clock to work. The file/directory time stamps need the system calls (and thus the clock) to work. If Finder worked but some applications do not, that's still pretty good.

The most comprehensive solution might be something like:
1. Find an unused PRAM byte to act as a high byte, giving us a 40-bit (8 + 32) range for dates/times. That will last 34 thousand years.
2. Update the System trap calls to be able to use this new range.
3. Update the file system calls to store the extra byte for the each of the dates in the FXInfo fdUnused field and DXInfo frXFlags field (not enough room -- maybe just some bits), assuming HFS+ isn't using those. Alternatively, encode the extra bytes to the end of the comment string. An invasive but powerful approach would be to inject a resource into each file with 64-bit LongDateTime timestamps. BinHex and Stuffit would preseve these.
4. Patch the Finder/Date&Time control panel to display/sort these extended timestamps.
5. Other applications wouldn't work without patching. File compression utilities might work without patching.

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.

This is probably the most compatible method of addressing it. We simply patch the System calls to display 32-bit dates with a '0' high bit as occurring after 2040. And patch the Date&Time control panel -- which is being done anyway due to the 2020 bug. Finder sorting isn't critical to address.

This avoids using any extra PRAM bytes or file bytes. Many applications would work without changes (as they just call the System routines to display the date/time). However, Norton Utilities would complain that the dates are too old. Incremental backup programs wouldn't work.

This would add another 70 years to the clock without many changes, and would not be incompatible or lost on non-patched systems.

- David
 

bigmessowires

Well-known member
Does anyone have insight into why Apple chose January 1, 1904 as the time base? Is that a standard? If they'd chosen a time base in the year that Mac development started, around 1980, then we wouldn't be worrying about this problem until 2114.
 

LaPorta

Well-known member
Does anyone have insight into why Apple chose January 1, 1904 as the time base? Is that a standard? If they'd chosen a time base in the year that Mac development started, around 1980, then we wouldn't be worrying about this problem until 2114.

Always wondered the same thing. I find it interesting that it ends with a 4 as 1984 was when the Mac was released.
 

bigmessowires

Well-known member
My first thought was that Apple deliberately chose a time base in the past, so that time values could be used for things like dates of birth and not just for the current time. But choosing 1904 would have made it impossible to encode the DOB of anyone over 80 at the time of the Mac's launch.
 

bigmessowires

Well-known member
The best explanation I've seen is that they wanted to start the time base on a leap year for some reason, and 1900 was not a leap year. So 1904 is the furthest back you could go without including 1900 in the range of supported dates, and needing to explicitly encode 1900 as an exception to the rule that every 4 years is a leap year. But then they could just have easily chosen 1908, or 1976. There's probably a TODO comment in the Mac 128K ROM source from Bud Tribble, reminding himself to pick a better time base after the next project milestone.
 

Crutch

Well-known member
This is probably the most compatible method of addressing it. We simply patch the System calls to display 32-bit dates with a '0' high bit as occurring after 2040. And patch the Date&Time control panel -- which is being done anyway due to the 2020 bug. Finder sorting isn't critical to address.

This avoids using any extra PRAM bytes or file bytes. Many applications would work without changes (as they just call the System routines to display the date/time). However, Norton Utilities would complain that the dates are too old. Incremental backup programs wouldn't work.

This would add another 70 years to the clock without many changes, and would not be incompatible or lost on non-patched systems.
I’ve given this a lot of thought also and implemented a chunk of this a few years ago, then lost interest because … we’ve got time.

But yeah we can make almost every application work by patching all of the various OS Utilities and International Utilities routines that mess with date/times: Secs2Date, IUDatePString, etc. Then every app that uses standard routines for converting dates and vice-versa to text would presumably work for input and display. The problem is that sorting and comparison would indeed be ruined, which would probably break a lot of things in annoying ways, at least in the immediate aftermath of the cutover. I am not sure this is fixable without patching every application separately, since lots of apps probably grab Date2Secs then just do direct long compares on the ‘secs’.
 

David Cook

Well-known member
The best explanation I've seen is that they wanted to start the time base on a leap year for some reason, and 1900 was not a leap year. So 1904 is the furthest back you could go without including 1900 in the range of supported dates, and needing to explicitly encode 1900 as an exception to the rule that every 4 years is a leap year. But then they could just have easily chosen 1908, or 1976. There's probably a TODO comment in the Mac 128K ROM source from Bud Tribble, reminding himself to pick a better time base after the next project milestone.

Yes! Exactly. Here is the formula used since the original Mac ROM:

1. clock_seconds / 86400 = days_since_Jan_1_1904, with the remainder being seconds_since_the_start_of_the_day

2. seconds_since_the_start_of_the_day / 3600 = hours, with the remainder being seconds_since_the_start_of_the_hour
3. seconds since the start_of_the_hour / 60 = minutes, with the remainder being seconds

4. (days_since_Jan_1_1904 * 4) / 1461 = years_since_1904, with the remainder being days_since_the_start_of_the_year. They multiply * 4 and divide by 1461 to avoid dividing by floating point 365.25.
5. 1904 + years_since_1904 = year
6. if year mod 4 = 0 then days_til_March = 60 otherwise days_til_March = 59. Because Jan = 31 + Feb = 28 or 29.
7. if days_since_the_start_of_the_year < days_til_March, then starting_month = 1, otherwise starting_month = 3 and subtract days_til_March from days_since_the_start_of_year.
8. ((days_since_the_start_of_year*128)+71)/3919 = magic_month_number, remainder magic_day_number
9. magic_month_number+starting_month = month
10. (magic_day_number /128) + 1 = day

Steps 8, 9, and 10 demonstrate how a little funky math can avoid tables or branches when you need to conserve ROM space and/or have a slow machine.

Step 6 will fail at the year 2100, because it is NOT a leap year. It requires more thought as to whether both Steps 4 and 6 fail thereafter, or if it takes missing four leap days until it is off by enough to affect integer math.

Step 6 also explains why they chose to start at 1904. For the mod 4 = 0 trick to work, you need to start on a leap year and not skip any /4 leap years. 1900 was not a leap year, but year 2000 was (/4=leap,/100=no leap,/400=leap).

In summary, these problems are caused by space-efficiency. This isn't even getting into the lack of leap seconds, time zones, or daylight savings time calculations...

- David
 
Last edited:

David Cook

Well-known member
then lost interest because … we’ve got time.

That's how I feel. I began writing the time patch code last year, then I got interested in System 6.0.8L patches, then I thought it would be nice to build the time fix into System 6.0.8L while I was at it. At this point, I figure it is most helpful to keep the conversation going to see if anyone has an ingenius solution.
 

Crutch

Well-known member
Step 6 also explains why they chose to start at 1904. For the mod 4 = 0 trick to work, you need to start on a leap year and not skip any /4 leap years. 1900 was not a leap year, but year 2000 was (/4=leap,/100=no leap,/400=leap).
As written step 6 would work starting from any year, right? For example 1901.
 

David Cook

Well-known member
As written step 6 would work starting from any year, right? For example 1901.
Ahhh! Yes. In my head, I figured that some part of the calculation either needs to start on a leap year or the year immediately following so that the day count integer math comes even with the floating point result. But, you're right -- it's not step 6 where that matters.
 
Top