IP: Two possibly unaddressed Y2K problems

[Dave Farber <farber@cis.upenn.edu>]

>
>Date: Thu, 30 Dec 1999 16:52:36 -0700
>To: Dave Farber <farber@cis.upenn.edu>
>From: Brett Glass <brett@lariat.org>
>Subject: Two possibly unaddressed Y2K problems
>
>While performing a Y2K check of a client's computers, I discovered a small 
>program, written in BASIC, which suggests an entire class of potential Y2K 
>glitches which has not been publicized and may plague us on or after 
>January 1, 2000.
>
>In the client's back office was an older PC attached to a modem. Each time 
>the computer was booted, it ran a simple program which instructed the 
>internal modem to make a brief telephone call to a telephone number 
>somewhere in Colorado. Upon connecting, the computer received the date and 
>time, set its clock accordingly, and then hung up.
>
>Inspection of the program revealed that it received and used only two 
>digits for the year.
>
>What number was the computer calling? After a bit of snooping on the 
>Internet, I discovered that the number was that of the Automated Computer 
>Time Service (ACTS), provided by NIST (the National Institute of Science 
>and Technology, previously known as the National Bureau of Standards). The 
>time message received by the program, derived from an atomic clock, looks 
>like this:
>
>JJJJJ YRMODA HH:MM:SS TT L DUT1 msADV UTC(NIST) OTM
>
>Where
>
>JJJJJ is the Modified Julian Date (MJD);
>YRMODA is the date (two digits each for year, month, and day); and
>HH:MM:SS is the time in hours, minutes, and seconds.
>(The remaining fields are documented online at 
>http://www.bldrdoc.gov/timefreq/service/acts.htm.)
>
>What is interesting is that the BASIC program provided by the NIST itself 
>(the same agency, ironically, which distributes the Malcolm Baldridge 
>quality awards and offers Y2K help to small businesses) ignored the Julian 
>date and used only the two-digit year to set the computer's clock. This 
>software was posted on the Internet by the NIST until approximately last 
>October.
>
>While ACTS can be used in a Y2K-compliant manner, the way to do this is 
>somewhat arcane (few programmers understand the concept of a Julian date, 
>and conversion is tedious). Perhaps this is why the NIST's own software -- 
>which was doubtless used verbatim or as the basis for other programs -- 
>cut corners, as most programmers were likely to do, and used only the two 
>digit "YR" code for the year.
>
>According to the NIST's ACTS Web page 
>(http://www.bldrdoc.gov/timefreq/service/acts.htm), more than 10,000 
>computers call the NIST's number each day. How many are running that old 
>BASIC program, or similar ones published on computer bulletin boards, in 
>magazines, or on the Internet, which have the same flaw?
>
>But wait.... It gets worse. Apparently, the time code transmitted by ACTS 
>is similar to that used by the NIST's radio stations --WWV, WWVH, and WWVB 
>-- to transmit time and date information the entire world. WWV's binary 
>coded decimal format, described on the Web at 
>http://www.boulder.nist.gov/timefreq/pubs/sp432/s_appb.htm, also uses only 
>two digits for the year. Worse still, the Julian date is not present, so 
>there is no way, using this code, to distinguish between the years 1900 
>and 2000.
>
>Alas, some digital logic circuits which interpret the codes from WWV, 
>WWVH, and WWVB are literally hard-wired to the existing format. (According 
>to some quick research I've done on the Net, these range from an old 
>Heathkit called "The Most Accurate Clock" to laboratory instruments to 
>traffic signal controllers.) So, the NIST does not have the option of 
>changing the format to include a 4-digit year for fear of breaking this 
>equipment. Unfortunately, it is unclear whether owners of this equipment 
>are aware of the potential problems in these embedded systems -- some of 
>which, again, use hardwired digital logic rather than microprocessors. 
>Will traffic signals in Los Angeles and Orange County, which are said to 
>use WWV as a time standard 
>(http://www.odetics-its.com/showcase/TASK2-2/la.html), fail? Or will they 
>become confused about the day of the week and snarl traffic by using 
>"weekend" timings on a weekday, or vice versa? What other municipal, 
>scientific, or military embedded systems will go awry because they rely on 
>the NIST's 2-digit time codes?
>
>Ironically, while the NIST Web site contains an article 
>(http://www.nist.gov/y2k/embeddedarticle.htm) warning users to evaluate 
>embedded systems for Y2K compliance, I have been unable to find any 
>article in which the NIST mentions the format of its own time signals as a 
>potential source of Y2K problems. Today, when I used the "Advanced Search" 
>facility on the NIST's Web site to search for the call sign "WWV" together 
>with the term "Y2K" or "2000," it failed to turn up any hits whatsoever. 
>The NIST's Y2K compliance page, at http://www.nist.gov/y2k/nistcomp.htm, 
>lists both ACTS and the agency's "time synchronization" services as Y2K 
>compliant.
>
>Conclusions are left as an exercise for the reader.
>
>--Brett Glass
>