IP: There's no Y2K-fix there...

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

Date: Wed, 29 Dec 1999 10:55:46 -0800 (PST)
From: John Wharton <jwharton@netcom.com>
Message-Id: <199912291855.KAA15414@netcom.com>
To: farber@cis.upenn.edu
Subject: Re: Early victories?
X-UIDL: 392e4876e67be24a51dca10ba6a846ff

Dave--
I just now saw the John Locke-Wheaton posting on Y2K credit-card handling
that ended, "Let's hope that none of the other bugs are life threatening."
It looks like Oakland officials have their act together -- now -- but you
might want to include a preface to my "911" message pointing out that --
unchecked -- this WOULD have been a most-life-threatening oversight.
(Or you could just repost this addendum, suitably re-titled.)
--John Wharton


>Date: Wed, 29 Dec 1999 10:47:58 -0800 (PST)
>From: John Wharton <jwharton@netcom.com>
>To: farber@cis.upenn.edu
>Subject: There's no Y2K-fix there...
>
>Dave--
>
>KCBS radio is reporting this morning that the Oakland 911 Emergency call
>system has determined its call prioritization algorithm is, well,
>technically speaking, /not/ fully Y2K compliant yet.
>
>Apparently incoming calls are timestamped with just a two-digit year code.
>Normally the call routing software gives top priority to the oldest
>(=earliest) calls, as one would expect.
>
>Alas, this means that as of the Friday midnight roll-over, all pending
>calls will instantly be kicked to the bad end of the priority list.  As I
>interpret the news reports, the post-rollover calls will be stamped
>1/1/1900, and, naturally, anyone who "just" called -- at 11:58 Friday
>evening, say -- is in far less dire straits than people who have been
>on hold for nearly 100 years.
>
>Oakland's solution, the 911 officials say, will be that, starting at
>11:50pm or so, all not-yet-dealt-with calls will be transferred to a
>different phone system to ensure that they don't get lost.  Dispatchers
>can then continue dealing with existing emergencies while newer calls
>queue up normally until dispatchers again become available.
>
>(The moral?  It's probably best /not/ to have an emergency in Oakland
>during those last few minutes before midnight...)
>
>=====
>
>My first impression was that this was a terribly embarrassing oversight,
>for this problem not to have been "fixed" months ago.  Date-stamps being
>processed backwards is /exactly/ the textbook example of what happens
>when the year field overflows.
>
>On the other hand, it /does/ seem the problem will be terribly short-lived,
>affecting maybe five or ten minutes' worth of calls -- ever.  After 12:10am
>or so, then, and for the remainder of the next century, the original call
>prioritization algorithms should continue to work just fine.
>
>Whereas re-opening the program source, rejiggering the code, augmenting
>the data structures and so forth could quite plausibly introduce new
>problems and incompatibilities that might bedevil emergency call
>processing for months.
>
>Leading one to wonder: was this just an embarrassing oversight?  Or a
>deliberate, rational cost-benefit decision to leave sleeping codes lay?
>
>Happy Holiday, Dave.  Knock wood.
>
>   --John Wharton


******************

A Happy Holiday and a safe New Year

from Dave and GG Farber

******************