[From nobody Wed Sep 6 10:11:54 2017 Date: Sat, 27 Feb 1999 18:55:38 -0500 From: "Calvin Hughes" <Calvin@HILL.ci.detroit.mi.us> To: "Charles Brown" <CharlesB@CNCL.ci.detroit.mi.us> Subject: Y2K problems outside of Jan 1, 2000 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Rolling thunder: When the bug=20 will strike=20 =20 Only 8 percent of all date-related errors are expected to hit on Jan. 1, = 2000 * here are the other dates to watch=20 =20 By Mitch Ratcliffe ZDNN=20 =20 =20 =20 Feb. 4 * 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. 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. =20 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. =20 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. =20 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 recognizab= le 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. =20 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. =20 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. =20 If the GPS system rollover does cause problems, it will be in routing of = traffic.=20 If a company or agency is using an older GPS receiver, manufacture= d 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 some 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 triangulati= ng 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. =20 DEC. 31, 1999 =20 =20 =20 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. ]