While many IT shops will spend 1999 grappling with the year 2000 problem, other date related dilemmas are looming on the horizon, and one expert says the problems won’t end until a useful date standard is adopted.
Capers Jones, author and chief scientist with Burlington, Mass.-based consultant firm Artemis Management Services, spends a lot of his time collecting data on software and computer systems. His interest in date related issues was piqued after doing a project for a client that required date-related research.
Although he was already well acquainted with Y2K and knew that dates could pose problems for IT systems, he had no idea that issues existed on the level that he found.
“I realized that the year 2000 and the Euro were both big problems, and then from the fact that they crept up on us I began to look around and see if other problems in the same class might creep up on us. And it turns out that it will.”
The best way to avoid date problems like Y2K, Jones noted, is to establish a uniform method to record dates worldwide. “Even modern standards, like the ISO date standard, are fundamentally inadequate; the ISO standard can’t handle scientific dates. In fact, most calculations to deal with time can’t handle scientific things either.”
He suggests adding code numbers before the ISO standard date (year-month-date) that would signify what type of time is being recorded, be it scientific, Julian or astronomical.
Jones even plans to lobby for a worldwide conference to deal with date related issues, but said he won’t begin his efforts until at least next year.
“I want people to live through one of these problems and find out how bad it is…(then) it ought to be easy to get them to pay attention to the next bunch.”
The following is a brief compilation of non-Y2K date issues that could affect IT systems.
Global Positioning System roll over: GPS time is kept in 20 year or 1,024 week cycles. “Time zero” for GPS systems is Jan. 6, 1980. So roll over – when the date counter resets to zero and begins another 20 year cycle — will occur at midnight, Aug. 21, 1999. Fortunately, Capers said this method of keeping time has been well documented by vendors and most GPS manufacturers have addressed the problem. But human error is always a factor, and some programmers who built applications using GPS may not have accounted for the date reset.
Jones is worried about two problems in particular: GPS is used by banks to synchronize interest on international funds transfers, so interest glitches could crop up. “(And) electric power plants use the GPS time signals for actually synchronizing some of the generating equipment. So we may run into blackouts or power outages as a result of the GPS problem.”
The “nines” problem: programmers have often used the number string “9999” to signify the end of a program. The problem is that some software may interpret that string as a normal date: Sept. 9, 1999.
And in some Unix applications, 999,999,999 has been used to designate the end of a program. In Unix, that number can signify Sept. 8, 2001. Though the nines problem has been solved on many operating systems, it may still exist on older applications.
“And you’re assuming that you can get access to the source code and to the computer where the problem exists,” Jones said. “Now suppose it happens to be 500 feet under the Atlantic Ocean in an underwater offshore oil device in an embedded device…how do you fix that one?”
Jones would like to see the adoption of a standard end of file symbol for all operating systems that can’t be misinterpreted as a date.
Feb. 29, 2000: IT shops know by now that leap years can cause problems if systems can’t account for the extra day. Experts say sloppy programming and short-sightedness are responsible for this recurring problem.
One issue is that rules for determining leap years aren’t clear cut – they don’t come only in four year cycles. For instance, years divisible by 100 aren’t necessarily leap years, but years divisible by 400 are. And the effects of a missed day can touch everyone – in 1996, the last leap year, 60,000 people in Arizona were unable to buy lottery tickets on Feb. 29 because lottery machine software didn’t recognize the extra day.
The 2038 problem: C and C++ use a signed 32-bit integer for time-keeping functions, keeping track of times as the total number of seconds passed since Jan.1, 1970. A 32-bit integer can hold a maximum positive value of 2,147,483,647 seconds – which equates to Jan. 19, 2038. When the date rolls over, computers may believe it’s Jan.1, 1970 again, or even read a negative value, putting the date back to 1901.
This problem affects C and C++ in both Windows and Unix environments, as well as many embedded systems. Experts say this problem could rival year 2000 in seriousness, although the hope is many of these applications will be gone by 2038.
“On the other hand, we thought most of the older applications would be retired so we wouldn’t have the Y2K problem. That turned out not to be the way (it happened),” Jones said.
— with files from IDG News Service
