.
January 11, 1999, 09:06 PM
By Mitch Ratcliffe, ZDNN Dec. 31a
By the time the calendar flips to 2000, computer experts will already know how ugly things may get because many institutions and companies are starting their fiscal 2000 financial years in 1999.
Two key dates have already passed without major incident. But those were warm-ups for the main event, and observers will study several critical dates to gauge how computer systems respond to the errors.
Indeed, only 8 percent of all date-related errors will hit on Jan. 1, 2000, according to the Gartner Group, which believes the majority of Y2K errors will strike over the next three years in relatively equal portions. After 2001, the problems will sporadically continue to strike as "dormant code" in legacy applications occasionally triggers errors.
Two key dates have already passed without major incident: the start of fiscal years for 46 states on July 1, 1998, and for the federal government on October 1, 1998. On each date, government computers began to look forward into fiscal year 2000 to perform projections and calculate benefits. Errors were expected, and no significant interruption of government services occurred. But those were warm-ups for the main event, and observers will study several critical dates to gauge how computer systems respond to the errors.
PARTY HATS ON JAN. 1, 2000?
When the clock strikes 12:01 on Jan. 1, 2000, two critical formatting problems will converge with many computer applications looking ahead into 2000. The chances that an unrepaired Y2K problem could then trigger a problem are high. The result: miscalculation of expiration dates on time-sensitive inventories, errors in checks, under- or over-estimation of interest on credit accounts - and that's just for starters.
The U.S. expects some problems with unemployment benefits because of look-ahead calculations, beginning on Jan. 1, 1999. Thirteen states and the District of Columbia have applied short-term patches to their systems to enable them to continue to issue benefits checks.
Meanwhile, the new European currency, the Euro, goes into virtual use on Jan. 1, 1999. But the presence of Euro-denominated calculations in systems that previously dealt only with dollars, marks, pounds or other existing currencies could wreak havoc on transactions.
Many of these Jan. 1 problems will not appear until the second day of the year, because they will be processed in batches after the close of business or after midnight, so Jan. 2 may be the first date to generate recognizable errors.
JAN. 4, 1999
The first working day of 1999 is probably the most important date for getting a bead on how computers will handle Y2K problems. This will be the first day that new data will be entered in most systems that look ahead to 2000. New data represents risk, because older files may be isolated from date-based calculations. For example, if you buy a television set on which you will not pay interest until 2000, the salesperson will enter the data into the store's computers, which will pass it along to the credit company computers for processing. If either of these systems has a Y2K problem, now is the time it will malfunction.
What do you want to look for as evidence of problems on these early 1999 dates? Well, headlines exclaiming the loss of benefits checks by pensioners are a good place to start. But also keep an eye on your own bills, particularly the ones generated by Christmas buying, which will begin to accrue interest in January 1999. A late invoice or an error on your bank statement will tell you that this is a company to keep your eye on.
WATCH THESE DATES
Each of the following dates marks the beginning of an important fiscal year for government. On April 1, Canada, Japan and New York state begin their Fiscal Year 2000. Forty-six states begin Fiscal Year 2000 on July 1. The U.S. government starts its Fiscal Year 2000 on Oct. 1.
For all intents and purposes, these dates are the real beginning of 2000 for government benefits and programs. And, because government is the largest consumer of virtually every product and service on earth, it is a
critical date for suppliers and companies that depend on payments from government. If errors occur in government computers, interfering with the payment of Social Security, Medicare, veterans or other benefits, a large and very influential segment of the population will immediately be in an uproar.
Two indicators to keep an eye on are: the earnings warnings of companies that are highly dependent on government for their revenues - an
interruption in government procurement processes or payments will show up in these corporate statements about upcoming earnings; and the credit/bond ratings for these governments, which would be downgraded if there were a change in their ability to pay creditors.
APRIL 4, 1999, AND SEPT. 9, 1999
These are the infamous "Nines Problem" dates, which may be interpreted by computers as either nonsense dates or an order to end all processes. Programmers sometimes used a string of four nines in the date field to denote infinity, which would be understood by the application as a date that didn't exist, or to indicate an "end of process" that would shut down the application. April 4, being the 99th day of 1999, and Sept. 9, being the ninth day of the ninth month of 1999, are expected to trigger some of these "nines problem" errors. If it happens, it will be proof that programmers' shorthand can produce terrible problems and would indicate that applications are also highly susceptible to date-related errors around the beginning of 2000.
In our opinion, the Nines Problem is a massive red herring. Neither of these dates would be formatted as "9999," since even Y2K-susceptible applications use a six-digit date field (00/00/00) to represent the date April 4, 1999, would be formatted as "04/04/99" and Sept. 9, 1999, as "09/09/99. "The "9999" string was selected as a nonsense or end-of-process date because it would not occur in normal operations using dates recognizable to humans. Granted, some programmers may have erred and used date formats that generate "9999" (for instance by counting the days of the year, not the day of the month, you would get "9999" on April 4th). This will be the rare exception, not the rule, since at minimum applications accommodate six-digit dates.
JULY 1, 1999
If the look-ahead calculations performed during 1998 and early 1999 don't generate errors, July 1 represents one of the last critical dates for this type of error. Applications that apply six-month windows to processes will begin to perform calculations using post-1999 dates on July 1.
AUG. 22, 1999
The Global Positioning System, the network of satellites that allows planes, trains and other infrastructures to identify the precise location of a receiver on or above the earth's surface, reaches the end of its built-in calendar at midnight, Greenwich Mean Time, on Aug. 22. The system will roll over and start at the beginning of the calendar again, operating for approximately 20 years (1,024 weeks to be exact). Some people expect massive logistical errors on this date. If the GPS system rollover does cause problems, it will be in routing of traffic.
If a company or agency is using an older GPS receiver, manufactured before 1994, there is a chance that the rollover will affect the management of traffic. The GPS system does count time in weeks (actually it's weeks 0 - 1,023, for a total of 1,024, which soe argue is another problem, that GPS systems won't be able to deal with a "0" week. It won't be a problem.) However, the week does not come into play in a GPS calculation, except at the instant the system rolls over. GPS calculations deal in milliseconds. A GPS receiver determines its position by triangulating difference in the time it takes for signals from two GPS satellites to reach it, a matter of milliseconds. The only time the week would enter into the calculation is as the system rolls over from Week 1,023 to Week 0.
A GPS receiver that is not prepared for the date rollover would think that one or both of the satellites had taken 18 years to send a signal that should have taken less than a second. It could not calculate its position accurately. In some cases, the receiver would simply fail to function, but in most cases it would just produce a weird reading. Most
commercial users of GPS have upgraded their systems. For example, the Federal Aviation Administration, a major user of GPS data, has upgraded its systems to handle the system rollover, as have airlines.
If the GPS system rollover does cause problems, it will be in routing of traffic. An airport with an outdated GPS receiver would have to revert to ground-based positioning systems, like radar. But, as noted, the likelihood of a GPS system error is low, because almost all hardware in the U.S. has been upgraded.
DEC. 31, 1999
By the last day of 1999, there will be plenty of data for analyzing what will happen as the calendar rolls over to 2000 across the globe. This, however, will be the most interesting and, possibly, anticlimactic day to come along in a long time, perhaps since, at the end of the first millennium, rapture-watchers were disappointed by Christ's failure to return.
Throughout the day on Dec. 31, parts of the world will be entering 2000 ahead of others. Likewise, some computers have been programmed to treat this date as nonsense, when the computer is no longer supposed to function. Many computers expected to fail on Jan. 1, 2000, may do so today if they have not been repaired.
The global air traffic control system will roll over to 2000 all at once, at midnight, Greenwich Mean Time, on Dec. 31, or at six o'clock in the evening in New York and three in the afternoon in San Francisco. That's the time to watch the skies, and the airports, for disaster and long lines.
~~~~~~~~~~~~~~~~~~~~~~~
Mykl's Note:
Folks this is posted as an FYI. It is too long to use as a thread starter, hence the lock on it. Please make comments to the "other" Y2K thread started by GrayFox.
Thanx!
[This message has been edited by Mykl (edited 01-11-99).]
By the time the calendar flips to 2000, computer experts will already know how ugly things may get because many institutions and companies are starting their fiscal 2000 financial years in 1999.
Two key dates have already passed without major incident. But those were warm-ups for the main event, and observers will study several critical dates to gauge how computer systems respond to the errors.
Indeed, only 8 percent of all date-related errors will hit on Jan. 1, 2000, according to the Gartner Group, which believes the majority of Y2K errors will strike over the next three years in relatively equal portions. After 2001, the problems will sporadically continue to strike as "dormant code" in legacy applications occasionally triggers errors.
Two key dates have already passed without major incident: the start of fiscal years for 46 states on July 1, 1998, and for the federal government on October 1, 1998. On each date, government computers began to look forward into fiscal year 2000 to perform projections and calculate benefits. Errors were expected, and no significant interruption of government services occurred. But those were warm-ups for the main event, and observers will study several critical dates to gauge how computer systems respond to the errors.
PARTY HATS ON JAN. 1, 2000?
When the clock strikes 12:01 on Jan. 1, 2000, two critical formatting problems will converge with many computer applications looking ahead into 2000. The chances that an unrepaired Y2K problem could then trigger a problem are high. The result: miscalculation of expiration dates on time-sensitive inventories, errors in checks, under- or over-estimation of interest on credit accounts - and that's just for starters.
The U.S. expects some problems with unemployment benefits because of look-ahead calculations, beginning on Jan. 1, 1999. Thirteen states and the District of Columbia have applied short-term patches to their systems to enable them to continue to issue benefits checks.
Meanwhile, the new European currency, the Euro, goes into virtual use on Jan. 1, 1999. But the presence of Euro-denominated calculations in systems that previously dealt only with dollars, marks, pounds or other existing currencies could wreak havoc on transactions.
Many of these Jan. 1 problems will not appear until the second day of the year, because they will be processed in batches after the close of business or after midnight, so Jan. 2 may be the first date to generate recognizable errors.
JAN. 4, 1999
The first working day of 1999 is probably the most important date for getting a bead on how computers will handle Y2K problems. This will be the first day that new data will be entered in most systems that look ahead to 2000. New data represents risk, because older files may be isolated from date-based calculations. For example, if you buy a television set on which you will not pay interest until 2000, the salesperson will enter the data into the store's computers, which will pass it along to the credit company computers for processing. If either of these systems has a Y2K problem, now is the time it will malfunction.
What do you want to look for as evidence of problems on these early 1999 dates? Well, headlines exclaiming the loss of benefits checks by pensioners are a good place to start. But also keep an eye on your own bills, particularly the ones generated by Christmas buying, which will begin to accrue interest in January 1999. A late invoice or an error on your bank statement will tell you that this is a company to keep your eye on.
WATCH THESE DATES
Each of the following dates marks the beginning of an important fiscal year for government. On April 1, Canada, Japan and New York state begin their Fiscal Year 2000. Forty-six states begin Fiscal Year 2000 on July 1. The U.S. government starts its Fiscal Year 2000 on Oct. 1.
For all intents and purposes, these dates are the real beginning of 2000 for government benefits and programs. And, because government is the largest consumer of virtually every product and service on earth, it is a
critical date for suppliers and companies that depend on payments from government. If errors occur in government computers, interfering with the payment of Social Security, Medicare, veterans or other benefits, a large and very influential segment of the population will immediately be in an uproar.
Two indicators to keep an eye on are: the earnings warnings of companies that are highly dependent on government for their revenues - an
interruption in government procurement processes or payments will show up in these corporate statements about upcoming earnings; and the credit/bond ratings for these governments, which would be downgraded if there were a change in their ability to pay creditors.
APRIL 4, 1999, AND SEPT. 9, 1999
These are the infamous "Nines Problem" dates, which may be interpreted by computers as either nonsense dates or an order to end all processes. Programmers sometimes used a string of four nines in the date field to denote infinity, which would be understood by the application as a date that didn't exist, or to indicate an "end of process" that would shut down the application. April 4, being the 99th day of 1999, and Sept. 9, being the ninth day of the ninth month of 1999, are expected to trigger some of these "nines problem" errors. If it happens, it will be proof that programmers' shorthand can produce terrible problems and would indicate that applications are also highly susceptible to date-related errors around the beginning of 2000.
In our opinion, the Nines Problem is a massive red herring. Neither of these dates would be formatted as "9999," since even Y2K-susceptible applications use a six-digit date field (00/00/00) to represent the date April 4, 1999, would be formatted as "04/04/99" and Sept. 9, 1999, as "09/09/99. "The "9999" string was selected as a nonsense or end-of-process date because it would not occur in normal operations using dates recognizable to humans. Granted, some programmers may have erred and used date formats that generate "9999" (for instance by counting the days of the year, not the day of the month, you would get "9999" on April 4th). This will be the rare exception, not the rule, since at minimum applications accommodate six-digit dates.
JULY 1, 1999
If the look-ahead calculations performed during 1998 and early 1999 don't generate errors, July 1 represents one of the last critical dates for this type of error. Applications that apply six-month windows to processes will begin to perform calculations using post-1999 dates on July 1.
AUG. 22, 1999
The Global Positioning System, the network of satellites that allows planes, trains and other infrastructures to identify the precise location of a receiver on or above the earth's surface, reaches the end of its built-in calendar at midnight, Greenwich Mean Time, on Aug. 22. The system will roll over and start at the beginning of the calendar again, operating for approximately 20 years (1,024 weeks to be exact). Some people expect massive logistical errors on this date. If the GPS system rollover does cause problems, it will be in routing of traffic.
If a company or agency is using an older GPS receiver, manufactured before 1994, there is a chance that the rollover will affect the management of traffic. The GPS system does count time in weeks (actually it's weeks 0 - 1,023, for a total of 1,024, which soe argue is another problem, that GPS systems won't be able to deal with a "0" week. It won't be a problem.) However, the week does not come into play in a GPS calculation, except at the instant the system rolls over. GPS calculations deal in milliseconds. A GPS receiver determines its position by triangulating difference in the time it takes for signals from two GPS satellites to reach it, a matter of milliseconds. The only time the week would enter into the calculation is as the system rolls over from Week 1,023 to Week 0.
A GPS receiver that is not prepared for the date rollover would think that one or both of the satellites had taken 18 years to send a signal that should have taken less than a second. It could not calculate its position accurately. In some cases, the receiver would simply fail to function, but in most cases it would just produce a weird reading. Most
commercial users of GPS have upgraded their systems. For example, the Federal Aviation Administration, a major user of GPS data, has upgraded its systems to handle the system rollover, as have airlines.
If the GPS system rollover does cause problems, it will be in routing of traffic. An airport with an outdated GPS receiver would have to revert to ground-based positioning systems, like radar. But, as noted, the likelihood of a GPS system error is low, because almost all hardware in the U.S. has been upgraded.
DEC. 31, 1999
By the last day of 1999, there will be plenty of data for analyzing what will happen as the calendar rolls over to 2000 across the globe. This, however, will be the most interesting and, possibly, anticlimactic day to come along in a long time, perhaps since, at the end of the first millennium, rapture-watchers were disappointed by Christ's failure to return.
Throughout the day on Dec. 31, parts of the world will be entering 2000 ahead of others. Likewise, some computers have been programmed to treat this date as nonsense, when the computer is no longer supposed to function. Many computers expected to fail on Jan. 1, 2000, may do so today if they have not been repaired.
The global air traffic control system will roll over to 2000 all at once, at midnight, Greenwich Mean Time, on Dec. 31, or at six o'clock in the evening in New York and three in the afternoon in San Francisco. That's the time to watch the skies, and the airports, for disaster and long lines.
~~~~~~~~~~~~~~~~~~~~~~~
Mykl's Note:
Folks this is posted as an FYI. It is too long to use as a thread starter, hence the lock on it. Please make comments to the "other" Y2K thread started by GrayFox.
Thanx!
[This message has been edited by Mykl (edited 01-11-99).]