The 2040 issue.

[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 

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]

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 

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]

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.

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

[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]

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

[IIO]

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

[nanopico]

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.

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.

[IIO]

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.

[nanopico]

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.

[nanopico]

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.

[nanopico]

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.

[Texas_RangerAT]

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.

[nanopico]

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.

[Texas_RangerAT]

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.

[nanopico]

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.

[darthnVader]

Not sure what event 1904 represents, Apple is funny, when you think about it, the Apple with a bite taken out of it, is, of course, a reference to the fruit of the tree of knowledge.( Even tho that was a fig, it's most commonly depicted as an Apple ).


So 1904, must hold some deeper meaning, but I have no clue what that would be.

[IIO]

beside the unknown origin there is another weird bit. the mac does not start counting the date from 0 but only from 1, so it does not know about the 1.january.

that is a common problem for excel users, who always have to decide if they want to use the 1.1.1900 or the 2.1.1904 as reference - or convert between them.

[OS923]

On https://68kmla.org/forums/index.php?/topic/28814-writing-a-system-extension/ they wrote:

Since my last post I've also put some thought into it, I hate the idea of screwing up the timestamps on everything so I was actually leaning toward reusing some of the dates prior to 1984 since it's impossible for any timestamps to actually occur before the mac itself.
 
The Gregorian Calendar repeats itself every 28 years, so it might be easiest to simply set the clock back to the earliest compatible calendar year prior to 1984, and then hack the display routines to add however many years to the system year to make it display the current year whenever it encounters a date that occurs before 1984.
 
Depending on if it's possible to override system routines with an extension, I believe the routines in question would be DateToSeconds() and SecondsToDate()

That's the correct approach.

They replied:

Attemting to change the interpretation of timestamps is going to be an extremely painful exercise. You can patch the system software, but then there will be piles of applications that decide to handle dates and times themselves. Either fully or partially and in all combinations. It will be a complete disaster.

The date time toolbox calls are very old. I think that most programmers know those calls and would find it silly to do their own calculation if they store their date and time as UInt32.

Patching DateToSeconds and SecondsToDate is the solution.

Has anyone ever seen source code of a working extension that patches DateToSeconds and/or SecondsToDate? The old names are Date2Secs and Secs2Date. They are 68K one word inlines, TB calls, not OS calls.

[IIO]

that is what i also would suspect; if you actually hack everything system time - but not how it is displayed, it will cause trouble for 500 apps. but if you hack both the system time and also how it is displayed, it will cause trouble for 500 other apps.
the only thing what is easy is to set internet sychronisation to off by default and remove the ioption to turn it on again from the controlpanel. everything else is a mess.

[OS923]

Well, as a matter of fact, I've done it already on Sunday. I've set my clock beyond 2040 and I patched DateToSeconds and SecondsToDate. There's was one extension that couldn't take it (Energy Saver) and then when the desktop appeared Finder crashed. But it's a start.

So now I want to see how other people patch DateToSeconds and SecondsToDate and then maybe I'll see my mistake.