PRESS RELEASE
The Year 2038 Problem & Pc-Check
by James Ling, Senior Engineer, Eurosoft (UK) Ltd.
July 2006
The year 2038 is a general computer industry problem. In the standard C programming language libraries (Posix compliant standard libraries) there is a representation of the time and date that encapsulates both into a single 32 bit signed integer value called 'time_t'. This value is the number of seconds that have elapsed since January 1st, 1970 (UTC). It is a useful representation because it provides a constantly increasing value which seamlessly crosses midnight, leap years and so forth, and so gives a simple way to implement items such as time outs, low resolution delays, and temporal messages, in a program by simply taking the current value for 'now', adding the required number of seconds and then waiting for that value to be exceeded. Unfortunately, with a signed 32 bit value, the 2 billion seconds that it can represent run out in mid January, 2038. Because of the wide popularity of the C language and the simple, easy to manipulate format, this problem is pervasive throughout operating systems and applications including such familiar items as the ZIP file format.
These links give further detailed information on the problem:
http://en.wikipedia.org/wiki/Year_2038_problem
http://www.deepsky.com/~merovech/2038.html
How Pc-Check protects against the problem
Having had an active role in issues surrounding the Millennium Bug, the Pc-Check engineers have not only been aware of this issue but have also taken measures to protect against the unwelcome effects that it can have on the program. They have ensured that Pc-Check does not perform calculations that might cause overflow of the representation - the longest calculations using the format are in calculating duration of a single run of a burn-in. They realised that while Pc-Check will have evolved considerably before such a date becomes a present day worry, the possibility for incorrect dates due to entry or malfunction should not cause unpredictable results from the diagnostic. To this end they added initialisation code to the program that will set all system dates to January 1st, 2037 (over a year ahead of the problem date) if that date has been exceeded on the system and so is clearly incorrectly set. This is done using a different, field driven call method not dependant on the time_t representation.
How this failed
As an example, the Pc-Check 'date normalisation' function was seen to operate successfully for dates such as 2040, pulling the date back to 2037 so that the time_t representation is not overflowed, however the year 2053 appears to be ignored in his tests - the following explains how this happens and is dependant on the BIOS type (Phoenix in this case, although others may have the same implementation).
One common solution to the year 2000 problem, particular for the simple setting of the year in many devices from video recorders through to PC BIOS is to use a 'pivot' year based on the last two year digits to decide the first two, or century, digits (sometimes referred to as the see-saw method). For most PC systems that use this method, the pivot is typically 80 because this year has significance to MS-DOS date storage. That is to say that if the year expressed as two digits falls in the range 00-79 the full year is 2000-2079, while 80-99 become 1980-1999. You will remember that the time_t representation is calculated from the UTC baseline of January 1st, 1970 - so all dates are also able to be represented in this form up until the representation breaks down in 2038.
In the example noted above, the Phoenix BIOS uses a pivot at the end of year of 50 instead, such that 00-49 become 2000-2049, but 50-99 are 1950-1999. When setting the date in an OS such as DOS or Windows, because the OS maintains its own copy of date and time rather than to continually access the RTC, the date will appear correct until after the next reboot. Because of the unusual choice of pivot year in the BIOS, the values 1950 through 1969 are able to reach Pc-Check and are not trapped by the 'date normalisation' because there exists only an upper limit, but no lower limit in the check. These year values are now below the minimum value of 1970 that a time_t variable can represent (most likely becoming a negative value counting back toward zero and, which in some cases, may be treated as a large positive value counting backward). Clearly, either of these conditions will be unexpected of a value representing the current time and date, and are unlikely to be trapped with unexpected behaviour becoming the only expectation
What can be done about this
In the next full release of Pc-Check, the date normalisation function will be changed to also trap years that are less than 1970 and bring them to January 1st, 1970 and so within range of the time_t calculations. In the next 30 years, Pc-Check will evolve to use 64 bit and eventually completely new standards for such calculations!
More on that unpredictable behaviour and the coprocessor
As discussed above, it has been long understood that dates beyond 2038 would have a widely disruptive effect on Pc-Check, not least because many user interface messages and burn-in timings rely on time_t, so just about any part of the program can experience problems. There has never been a formal study of the nature of the effects generated. In the specific case of multi-processing, all diagnostics' code that executes on secondary processors is monitored by the boot-strap processor for time out, this monitoring uses the time_t representation. If time_t values are in error, the secondary processor will immediately be thought to have locked up and so the boot-strap will attempt to reset the CPU occurring before it has even completed initialisation. The result of this is the likely double fault of a processor causing a system reset or a test failure depending on how the reset signal is then propagated in the motherboard design.
About Eurosoft (UK) Ltd.
Eurosoft (UK) Ltd., a private, limited company, located in Bournemouth, England has provided diagnostic and system management software, and hardware test solutions for PC assemblers, system integrators and computer service professionals since 1980. Eurosoft's acquisition of the Sykes Diagnostic Division (NASDAQ: SYKE), September 19, 2001 extended its diagnostic solution offering and customer base worldwide. Eurosoft's office locations include Providence, Rhode Island and Issaquah, Washington, USA, with the head office in Bournemouth, England.
