The NewtonOS has a bug in handling years past 18:48:31 on January 5, 2010. The bug is located in the NewtonScript interface of certain time functions, and it is caused by an overflow of a NewtonScript integer value. This bug seems to only occur in NewtonOS 2.1 devices.
In case of problems, the Y2010 Diagnostic application can be used for initial first aid
Symptoms
The overflow of the timer causes alarms to go off in an endless loop. Alarms can be shown for example for calendar events, to do items or birthdays. The alarm notification can be dismissed, but will reappear immediately because due to the overflow, the time for the alarm is in the past.
Solution
A solution has now been released as a set of patches for the different NewtonOS 2.1 devices:
- Patch 711000: Patch for the US MessagePad 2000 and 2100
- Patch 73J186: Patch for the eMate 300
- Patch 74J185: Patch for the German MessagePad 2100
The Newton Clock
On 2.1 devices, the Newton has one high resolution realtime clock. The interface to the RTC is the TURealTimeAlarm class in LongTime.h. Time values are stored in obbjects of the TTime class. The RTC can handle very large time spans, but most of the functions use unsigned 32 bit integers as seconds from January 1st 1904.
Classes and Functions
C++
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.
NewtonScript
The NewtonScript functions are all based on the RTC, there is no separate clock maintained for the NewtonScript layer. They are based on the RealClock functions described above, and work with a minute or second resolution.
The Time function works with a time base of January 1st 1904. The TimeInSeconds function, and all functions using seconds as the resolution use a time base of January 1st 1993.
The Bug
The overflow happens in all NewtonScript functions which use seconds as the resolution. In contrast to the 32 bit unsigned integer used by the C++ functions, NewtonScript integers are only 30 bit wide. While the C++ functions can handle times from 1904 until 2040 without an overflow, the NewtonScript functions had to be designed with a smaller range of applicable times due to the limited precision.
The seconds-based functions are implemented by taking the value of the real-time clock, subtracting the offset to January 1st 1993, and converting the results to a NewtonScript integer. This limited range causes an overflow on Tuesday, January 5, 2010 at 6:48:31 PM.
This is the list of affected functions:
- SetSysAlarm
- TimeInSeconds
- TimeToTimeInSeconds
- TimeInSecondsToTime
Fix Possibilities
Rebasing the Minute based Time Functions
The problem of an overflow in the seconds based functions is caused by the system time advancing past the overflow time. By ensuring that the system time stays within the safe interval, the overflow can be avoided. This fix was implemented by Avi Drissman in the Fix2010 package. The Fix2010 uses the concept of a hexade (16 years) and adjusts all functions which use minutes as a time base to always fall into the safe interval, taking the offset for the hexade into account.
Rebasing the Seconds based Time Functions
A more low level approach is to change the offset used by the seconds based functions so that the safe interval starts and ends later.
Considerations
There are some pitfalls to consider for any fix. The parts of the NewtonOS which are not patched might activate before the patch goes into effect (e.g. when rebooting or after a cold boot), and some data might carry wrong values. So far, these issues are open:
- State of the clock after loss of time: The clock resets to 1996 in this case, and this value might conflict with the patched functions
- Alarms in the alarm soup: Alarm times can be wrong if the alarm was entered without the patch
- Hardcoded assumptions about the time bases: Programs assuming that the seconds-based functions always start in 1993 might stop working