Author Topic: The 2040 issue.  (Read 5322 times)

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 1933
  • keep it simple
The 2040 issue.
« on: November 21, 2015, 05:52:43 AM »
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.


Please don't PM about things that are not private.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #1 on: November 21, 2015, 06:37:03 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

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.

If it ain't broke, don't fix it, or break it so you can fix it!

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 1933
  • keep it simple
Re: The 2040 issue.
« Reply #2 on: November 21, 2015, 06:45:08 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.

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

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

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

http://lowendmac.com/lab/04/0115.html
Please don't PM about things that are not private.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #3 on: November 21, 2015, 07:07:03 AM »
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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 1933
  • keep it simple
Re: The 2040 issue.
« Reply #4 on: November 21, 2015, 10:49:22 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.

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.

Sorry, I don't fully understand this ... may be my low English skills  :'( ...
Please don't PM about things that are not private.

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1582
  • new to the forums
Re: The 2040 issue.
« Reply #5 on: November 21, 2015, 02:46:48 PM »
there is one thing which i dont understand.

when you turn internet time sync on, swatch internet time is not received as a stupid 32 bit number of seconds (what a weird idea!) but as 1/1000 day.
so with a 1/1000 day clock you can express many thousands of years with a 32 bit float.

so i believe that it should be possible to get the right day and hour in 2041, too.

i am just not sure about minutes i.e. if the internal clock will be able to run when it is "full" and can count no more. (if that is what happens, one could on the one hand set the year value 100 years back so that the clock runs again - but that means otoh you are no longer able to update with internet time - until you hack either the internet time sync extension or the date and time cdev.)
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #6 on: November 21, 2015, 07:35:35 PM »
there is one thing which i dont understand.

when you turn internet time sync on, swatch internet time is not received as a stupid 32 bit number of seconds (what a weird idea!) but as 1/1000 day.
so with a 1/1000 day clock you can express many thousands of years with a 32 bit float.

so i believe that it should be possible to get the right day and hour in 2041, too.

i am just not sure about minutes i.e. if the internal clock will be able to run when it is "full" and can count no more. (if that is what happens, one could on the one hand set the year value 100 years back so that the clock runs again - but that means otoh you are no longer able to update with internet time - until you hack either the internet time sync extension or the date and time cdev.)

Generally a hardware real time clock that reports an unsigned integer of any kind will just loop. It just keeps counting and incrementing it's value.  When it's full it overflows back to 0 and just keeps going.
For the network time protocol that is used, it is a 64 bit number.  One part is for the seconds and one is for fractions of a second (so that you can have synchronization between two devices that is very accurate).  NTP also has a limit of of 137 years, but it's epoch is actually 1900, so if your using network time with a mac you'll actually start to have issues in 2036.

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.

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

The side effects of any change are unknown and would require extensive testing.
Finding the epoch is time consuming, but not all that difficult.  I belive that while I was reading Inside Macintosh, it stated that the Operating system queries the real time clock once per second and updates the system date time.  You can poke through the assembly code (thus the time consuming part) until you find that query and then look at the code around it to find the data section it compares the query results to, then epoch found.
I think the Date Time control panel set the real time clock as well.  When you set a date in the control panel it calculates the number of seconds from the epoch and tells the real time clock to start counting from that number.  So the control panel would also have info about where the epoch is stored. Who knows how many places it's located at though.


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.

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

Yeah I just re-read that too.  It doesn't make a whole lot of sense.  Let me try again.
Update the Date Time calculations to check the RTC and a value stored on disc.  This value would be the number of times the RTC has overflowed.  (so it reached it's end and started at zero).  Multiple the two numbers together, calculate the date based on that new number and bam, you actually won't really ever have to worry about the date time ever running out.

If it ain't broke, don't fix it, or break it so you can fix it!

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1582
  • new to the forums
Re: The 2040 issue.
« Reply #7 on: November 23, 2015, 07:06:41 AM »
NTP also has a limit of of 137 years, but it's epoch is actually 1900, so if your using network time with a mac you'll actually start to have issues in 2036.

oh right, MacOS 8 were using NTP, sorry, i thought we are talking about swatch beats.

there might be two different methods how other applications are getting time from the system, it could be the actual 32 it value - then we have a problem - or it could be something like YYYY:MM:HH:MM:SS:Z, where only two bytes would be enough to last until the year of 9999.
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #8 on: November 23, 2015, 07:15:36 AM »
In NTP 4 it has been proposed to move to 128 bit (64 for the seconds since epoch and 64 for the fraction of the second your in.
There is Also support for Era and Era offset which would help define the epoch and define how many times the time stamp has rolled over so you really won't ever have an issue with dates again.  But that version isn't finalized yet.  Implementing it in OS 9 for network time would help, and what ever code is used for network time could be patched into the system for when your not on network time.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #9 on: December 12, 2015, 08:06:24 PM »
Here's one thing OS 9 has over os x.   The epoch for OS X is in 1902 instead of 1904.  So the clock in OS X will run out in 2037. 
I find this amusing.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #10 on: December 16, 2015, 06:36:44 AM »
A patch for the year 2040 issue will be sort of interesting as files have their modified and creation dates stored as the 32bit unsigned int returned by the real time clock.  The dates you see displayed are calculated when you view them.
So any implementation will have to account for that, but I have some ideas on how to handle it. 

Also this would probably affect any software that has a timed demo period (like 30 days or what not), but at this point I don't think I even care about that as most of that software has already been cracked and there really isn't much new stuff out there if any doing this sort of thing in OS 9.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Texas_RangerAT

  • Active Member
  • **
  • Posts: 20
  • new to the forums
Re: The 2040 issue.
« Reply #11 on: July 15, 2016, 04:31:47 PM »
Are you sure the epoch is 1904 for all macs and OS versions? I'm asking because I know there are Mac models that will reset the date to 1956 rather than 1904 if the PRAM battery is flat! Might even be all PPCs, I'd have to check that starting with a 7100 and maybe throw in a late 68k machine (Performa 630) just for fun if the 7100 already goes to 1956.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #12 on: July 16, 2016, 06:02:29 AM »
The OS uses the 1904 date.  As the ROM is a big part of it, it is possible that some ROM's don't reset to that date, but the date is still calculated off the 1904 date.  All your created/modified dates on files are based on that date, all code fragments in resources have a creation time stamp based on that date, everything is based around that date. It is not a hardware limitation as there are many ways to work around it, but as it's embedded in pretty much everything, a solution to the entire system is complex so as not to break existing functionality/programs that rely on that.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Texas_RangerAT

  • Active Member
  • **
  • Posts: 20
  • new to the forums
Re: The 2040 issue.
« Reply #13 on: July 18, 2016, 06:30:26 AM »
OK, that makes sense!

Some newer computers even go to 1970 when the battery dies, pity the OS doesn't recognise that - if it did I suppose fixing the issue would be much easier.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 656
Re: The 2040 issue.
« Reply #14 on: September 22, 2016, 09:09:55 AM »
Just wanted to update this a bit.  (Some of this has been said, but I'm thinking out loud and getting it all together).

So the year 1904 was chosen not only because it is a leap year and it's easier to calculate the date when the epoch starts on a leap year, but also because the max value of an unsigned int used as the number of seconds since 1904-1-1 at midnight  will sit in a date range where a leap year will occur every four years so the algorithm is very small and easy to calculate the date.  This was extremely important on the first Mac since all sort of stuff was placed in the ROM. 
The whole thing was kept for two reasons. One - backwards compatibility. Two - It worked so don't change it. 

After looking at some thing related to files/disk/volumes/partitions I realized that changing the epoch will also require changes to the code to calculate the date, though if the epoch is set to 1959-10-1 at midnight we can easily get to 2099 without changing the algorithm. The device manager and file managers will have to be updated to not freak out when they encounter strange dates.

Disks and volumes both contain fields in their header for the date of last backup.  Most backup programs utilize this. Depending on how they use this value, then they will become unreliable and things will not get backed up properly.

Files contain a creation and modification date.  This will no longer be accurate on non-patched systems, which again can cause issues with some programs that check that information.

AFP would need to be updated as well for network shares. 

All in all there will be a lot of areas to patch and compensate for.  It will be a massive undertaking, most of which will be in testing and verification of applications.

So having said that, I will not be attempting any patching to fix this issue at this time.  I may re-look at it in the future (before 2040), but for now don't count on any fix from me. Maybe someone else will want to take a stab at it.

If it ain't broke, don't fix it, or break it so you can fix it!