| Click here to select a new forum. |
| OS 7 End Date - 2020 |
Posted by: aplmak on 2015-11-28 22:44:11
To any programming folk out there... is there any way we can talk about a patch or an update someone can make to fix the system clock before the year 2020... It appears after that it reverts back to the roaring 20's.. 1920... Not sure if this is a hardware issue but I think it's a software thing.. seeing OS 7 has a 4 digit year...
I realize having an accurate date is not really essential... but I do play with files and like to just date stuff.. so I do like to keep track... so yes it's important to me... and we should probably start discussing this now... so it looks like we need a "Y2020 Fix" lol
|
Posted by: aplmak on 2015-11-28 22:47:41
And on my 2008 MacBook running OS 10.7.5 it appears 2037 is the end of the line...
|
Posted by: johnklos on 2015-11-28 23:08:23
Just add 2^32 seconds to get the correct time. Or, if it is simpler, add 100 years. There are plenty of ways to fix timestamps on files if exchanging files between systems becomes an issue.
|
Posted by: Schmoburger on 2015-11-28 23:17:43
And it seemed like not that long ago we were worried about Y2K and the world imploding! lol
|
Posted by: aplmak on 2015-11-28 23:25:50
It would be just great if someone on here can program a little patch file.. I would think someone could come up with a patch hack easily for this... someone with programming knowledge.. I'm not much of a programmer...
|
Posted by: yuhong on 2015-11-29 00:02:33
I think this is just for the Date/Time control panel, you can use another program to set the date and it will work fine.
|
Posted by: Apache Thunder on 2015-11-29 09:41:35
I hear calendars become re-usable every 28 years or so. You could just set the year back 28 years once you hit the limit and the day/month will still be valid. 😛
EDIT: Took a look at my PC's calender and that appears to hold true. I looked at November 1992, and the 29th still fell on a Sunday with the same amount of days in the month.
|
Posted by: TheWhiteFalcon on 2015-11-29 10:02:19
Should be patchable, I believe the OS9 guys are working on one, and obviously the Newton got one for 2010.
|
Posted by: james_w on 2015-11-29 15:24:06
What would be even neater would be to have patches for all systems, especially 6 & 7... but my 128 would probably like it for 5 too... and others on here would probably like it for 8 & 9 as well right?
|
Posted by: techknight on 2015-11-30 08:46:57
The thing I am wondering, is what is the physical limit of the RTC chip. That could be a problem as well, and one that isnt easy to overcome.Â
|
Posted by: VMSZealot on 2015-11-30 08:58:23
@techknight
The RTC shouldn't be a problem - as long as you can cope with never setting the date and time backwards. Â The system would need patching and updating so that, on going, dates that the RTC reports get incremented by 28 years. Â So if the RTC thinks that the date is 26th March 1994 the date reported by the system would be 26th March 2022.
It isn't just an issue with the date displayed by the system clock though - there may also be an issue with the timestamping of files.
|
Posted by: Paralel on 2015-11-30 16:40:49
Didn't BBraun create an extension that fixes this issue? I think it was called SetDate?
I fix this problem by just leaving the PRAM battery out so it always thinks its some time in the 1980's
|
Posted by: aplmak on 2015-11-30 22:22:01
Thanks Paralel!!! I found the SetDate program BBraun made!!!!!!!! WORKS GREAT!!!!! I tried 2039 and it froze.. not sure why.. but I did 2035 after restart and it was great!!! New folders stamped 2035.. 🙂
|
Posted by: Paralel on 2015-12-01 13:48:30
By trying 2039 you hit the "Year 2038 problem"
Any system, including Macs, that use a 32 signed integer for time will stop counting time properly at exactly 03:14:07 UTC on 19 January 2038. Its a well known issue in time keeping for 32-bit systems.
As far as I'm aware, fixing this is much, much more difficult.
So, by fixing the 2020 issue, we have just delayed the inevitable for another 18 years.
|
Posted by: yuhong on 2015-12-02 23:38:36
By trying 2039 you hit the "Year 2038 problem"
Any system, including Macs, that use a 32 signed integer for time will stop counting time properly at exactly 03:14:07 UTC on 19 January 2038. Its a well known issue in time keeping for 32-bit systems.
As far as I'm aware, fixing this is much, much more difficult.
So, by fixing the 2020 issue, we have just delayed the inevitable for another 18 years. Mac OS itself don't use time_t I think, but other programs may.
|
Posted by: NJRoadfan on 2015-12-03 06:29:08
Classic MacOS and the Apple IIgs clock (along with the still in use HFS+ file system) have a limit around February 6th 2040 as they use a different epoch then the UNIX time_t. Nobody cared about the poor Lisa though, its clock doesn't go past 1995!
|
Posted by: Paralel on 2015-12-03 14:21:19
Huh, I wonder why 2039 failed... Must be something to do with SetDate itself and how it works.
|
| 1 |