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