Title: The Clock is Still Ticking

On Tuesday 19th January 2038, at 3:14am and 8 seconds, the number of seconds since the start of 1970 will reach 2 raised to the 31st power. C and C++ programs that use signed 32-bit integers to represent time will behave as though it were suddenly 8:45pm and 52 seconds on Friday 13th December 1901, with potentially disastrous consequences. Before that, people who have coped with Y2K by putting the clock back may face "forgotten ghosts" of Y2K at various arbitrary times in the next few decades, as their backward clocks approach a belated 2000. Keep alert; it is not over yet.

The Y2K "ghosts" are probably a worse threat, since the 2038 problem is perhaps easier to deal with. Neither C nor C++ limit the length of int or long, so even programs that use 'int' or 'long' instead of time_t can still be made to be compliant by recompiling them on a 64-bit architecture with a compliant compiler and library. One would hope that by the 2030s it would be unthinkable to settle for a mere 32 bits even for pocket systems, or for 64 bits about 290 billion years from now and so on. Predictions are of course dangerous and it is always possible that there will still be a thriving application for architectures of 32 or fewer bits in 2038, or perhaps there will be many old computers that have been lost track of (the embedded systems problem). There is also the question of code involving nasty casting (or hand-coded assembler) that assumes that longs can be no longer than 32 bits; this code is not compliant with the standards anyway and the best thing today's programmers can do to avoid the problem is not to write such code.

The main immediate concern, however, is the expiry of the so-called "sliding window fixes", which put the clock back to postpone the year 2000. This is particularly true if some of the programmers who made such fixes did not document them adequately. It may be advisable for any Y2K response programmes to be re-named Date Dependency response programmes and to continue operating. Some of the more likely time shifts include all the "round" numbers (5 years, 10 years etc) and 28 years, because the days of the week repeat themselves every 28 years.

I wrote the first draft of this article on January 1, and suggested that there might be minor problems on February 29 and perhaps more serious problems on April 1 (the start of Japan's financial year). This did not seem to happen (even in the April Fool hoaxes) - the glitch in the London stock exchange was, as far as I know, unrelated. Another date that has been flagged by some is 10th October, which is the first date to require all eight digits when written in numerical form with four-digit years. However, "postponed 2000" is a potentially greater threat if it is not monitored.

When the rollover itself passed without nearly as much trouble as was anticipated by some, a number of media presenters concluded that "the bug [may have] never been there in the first place". This is incorrect; as listeners of BBC World Service's "Bugwatch 2000" series will know, the non-event was due to considerable effort. To take our guard down now would be to allow potential after-effects to bite unexpectedly. They are not (at present) any serious threat to life as we know it, but they might be a little embarrassing for those who slip into complacency.