Y2026 and beyond

[panicsteve]

There are additional Newton date bugs on the horizon...

Eckhart mentions one occurring in 2026: http://40hz.org/Pages/Mottek:%202016-02-14

And I could've sworn I read a post on NTLK that there was a trickier one (32-bit overflow?) in 203X.

Are these patchable the same way as 2010 was, by moving the epoch date forward (at the possible risk of corrupting data prior to the change) or are the future date bugs more complicated? Anyone know?

Don't want them sneaking up on us!

[splorp]

The 32-bit overflow issue seems to be related to Y2040, not Y203x.

The more common C++ funtions are the RealClock and RealClockSeconds functions for reading the RTC, and SetRealClock and SetRealClockSeconds functions for setting the RTC. The base for these functions is always January 1st 1904, and the resolution is either minutes or seconds. The use of an unsigned 32 bit integer creates an overflow problem in the year 2040. In general, all C++ functions can be considered safe and problem free until 2040.

https://40hz.org/Pages/Newton%20Year%202010%20Problem

I wonder if @ekoeppen could chime in?

[ekoeppen]

Indeed there are two bugs coming up: The 2026 bug is the same as the 2010 bug, where the NewtonScript functions will overflow. Or to be more precise, there was only a 2010 bug, the 2026 problem is a result of the way I fixed it. But it can be easily fixed again, so that the next time it happens will be 2042 :)

I haven't checked how to fix the 2040 bug though, it might be a bit tricker in case the related C++ are either not patchable easily, or if the use of the unsigned integer is more pervasive. I suppose with Einstein, a lot of the things might still be easier than with real HW.

[MatthiasWM]

It would be great to integrate something (the decade solution?) with the enhancement https://github.com/pguyot/Einstein/issues/21 , integrating the patch into Einstein.

[MatthiasWM]

Ping. Believe it or not, it's 2022, and in four years, the bug will hit us. The last time we discussed this was, four years ago. I guess, time flies, and it would be nice to keep things running for another 16+4 years. After that, I am 76, and I probably won't care that much anymore ;-)

[ekoeppen]

Makes sense, I think it's probably first time to see how to build the patch, and then just adjust the offsets.

[splorp]

Hello @ekoeppen et al.

Just a quick reminder that we’re only two years away from 2026 and it’s related problem.

(Where the heck did that time go?)

[ekoeppen]

Oh dear, indeed, where did the time go? Maybe time to be concerned about the 2040 issue as well :) I'll see that I dust off my old build environment, anyway something that makes sense to start early on.

[splorp]

Never hurts to be proactive.

[MatthiasWM]

I looked at the source code and the binaries. If everything fails (if there is no way to restore a working build environment), I can write code that patched the binaries to the correct offsets for 2026 and following. I can't fix 2040 that way obviously.

I'd also like to remind everyone, that there is a complete tested and working ROM board for MP2x00 machines online that has flash chips instead of masks programmed ROM that can be flashed to contain any ROM and patch version. Not sure home much the boards would be now, but I think I paid something around 16 Euros per board, having the etched and soldered in China.

[splorp]

Something just occurred to me … since the Y2010 and Y2026 bugs only affect Newton OS 2.1 devices, is this still the case with the Y2040 bug?

[MatthiasWM]

Yes, the Y2040 bug is still there. Time for Apple to give us access to the ROM source code, so we can fix that... .

[splorp]

“Time for Apple to give us access to the ROM source code, so we can fix that...”

That would be very thoughtful of them, wouldn’t it? 😝

By the way, I recently added Y2040 to the Newton Glossary.