Classic Mac Hardware (Troubleshooting, Upgrading, & Modifying) > General Hardware Discussions

The 2040 issue.

(1/5) > >>

MacTron:
Apple picked 1/1/1904 as its base, time zero. All time was stored internally relative to that date. But Apple didnít store it as so many days, months, and years after the base; instead, the Mac tracked seconds since time zero usig a 32 bit number.

The 68k Macintosh will be able to count seconds until 6:28 a.m. on February 6, 2040. Better yet, every Power Macintosh ever built, since they use an even larger number, can count the seconds from time zero until sometime in A.D. 29,940.
However, even the Mac isnít quite perfect. In older versions of the Mac OS, the Date & Time control panel only lets you set dates from 1/1/1920 through 12/31/2019. In new versions of the Mac OS, the Date & Time control panel lets you set dates from 1/1/1904 through 2/5/2040. 

According Geoff Duncan:
If your computer is running system software released in the last decade System 6.X through Mac OS 8.6 it can handle dates from 30,081 B.C. to A.D. 29,940  :o

http://www.macworld.com/article/1015346/y2k.html

Confusing info, as always ...

But the issue isn't in to the Date & Time control panel IMHO, but into the System, because I have restarted without any extension or control panel and system couldn't pass 6:28:14 a.m. on February 6, 2040 anyway.


nanopico:

--- Quote from: MacTron on November 21, 2015, 05:52:43 AM ---According Geoff Duncan:
If your computer is running system software released in the last decade System 6.X through Mac OS 8.6 it can handle dates from 30,081 B.C. to A.D. 29,940  :o

--- End quote ---

This is really the most confusing part.  This statement is true when you call any of the api functions to convert, manipulate, compare dates that don't involve the system date/time.
Apple used this fact to say that it could handle such a large range and just kind of skipped over the system date/time info.

I know that linux/unix and os x doe the exact same thing for setting the system date.  Only difference is that their zero time (or usually referred to as the epoch) is some where int he 1970's or newer.  Why apple ever chose 1904 is beyond me for their epoch.

MacTron:

--- Quote from: nanopico on November 21, 2015, 06:37:03 AM ---I know that linux/unix and os x doe the exact same thing for setting the system date.  Only difference is that their zero time (or usually referred to as the epoch) is some where int he 1970's or newer.

--- End quote ---

... and they use a signed 32 bits number.


--- Quote --- Why apple ever chose 1904 is beyond me for their epoch.

--- End quote ---

"... in part because it's mathematically convenient to have a calendar system start on a leap year"

http://lowendmac.com/lab/04/0115.html

nanopico:
Make's sense to pick a leap year, but why not something more realistic like 1972, 1976.  They could have also used 1980, but considering the macintosh project start in 1979 and it in part was influenced/contained some parts of the Lisa which started in 1978 I could see using '76 for the year at least for system time.  As at the time there really was no practical reason to set your system clock to a date less than the current date.

In all seriousness though the whole subject is just fascinating to me really.

To fix it you can do one of two things. (if there are more then awesome.)
Change the epoch it uses to calculate the date. That will buy you 137 years. Trouble with that is than any system calls that do calculations that depend on the epoch date will need to be thoroughly tested for correctness.

The other way is a little trickier.  Add a counter stored on disk in say preference file or something, that counts the number of times the real time clock that provides the 32 bit value for calculating. You would have to detect the difference between a roll over and the pram just resetting, but you could put some rules in that guess at that with fairly descent accuracy.
Then you update/patch all call to get the seconds from epoch to accept a 64 bit unsigned int that would be the current 32 bit int value multiplied by the number of role overs that have occurred.  In theory all other date/time function would remain the same so it wouldn't be as important to test them, but they sure should be.

MacTron:

--- Quote from: nanopico on November 21, 2015, 07:07:03 AM ---Change the epoch it uses to calculate the date. That will buy you 137 years. Trouble with that is than any system calls that do calculations that depend on the epoch date will need to be thoroughly tested for correctness.

--- End quote ---

This method that's what I first thought that can solve the issue... but actually we don't know what kind of side effects can have, and where to find the epoch data to be changed ...


--- Quote ---The other way is a little trickier.  Add a counter stored on disk in say preference file or something, that counts the number of times the real time clock that provides the 32 bit value for calculating. You would have to detect the difference between a roll over and the pram just resetting, but you could put some rules in that guess at that with fairly descent accuracy.
Then you update/patch all call to get the seconds from epoch to accept a 64 bit unsigned int that would be the current 32 bit int value multiplied by the number of role overs that have occurred.  In theory all other date/time function would remain the same so it wouldn't be as important to test them, but they sure should be.

--- End quote ---

Sorry, I don't fully understand this ... may be my low English skills  :'( ...

Navigation

[0] Message Index

[#] Next page

Go to full version