How does a non-comlpiant computer corrupt a compliant one?greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
I do not know the technical process whereby a non-compliant computer can corrupt a compliant one. Obviously the communication between the two is by modem or ADSL, but can this also happen any other way? Will compliant computer systems just shut down the communication lines to stop having data defiled? I just don't know enough about how this happens to answer questions from friends. I probably come off looking like "Henny Penny" without the information to back up what I say. It is probably an easy answer - but I haven't learned it yet, as I just found how to navigate the net.
-- L. Parker (firstname.lastname@example.org), April 26, 1998
Let me give you a quick example of this from the Internet world with which I'm familiar. There are many, may other examples, but this one is pretty clear, so I like it.
I'm network operations manager for a regional ISP in one of the three largest metropolitan areas in the United States. We have a lot of general-purpose computers that run our infrastructure, such as Web, DNS, NFS, news, etc.
One of the things we've found no real reason to maintain is a time server -- there are public servers to do this all over the 'net.
It's important for certain applications to be synchronized with the rest of the world's time, so several times a day, all of our servers go and and talk to the server utcnist.microsoft.com. This is a public time server maintained by Microsoft, and since our company is largely made up of UNIX gurus, we find it amusingly ironic to be contributing to the sluggish nature of some NT machine somewhere by polling it for the time.
All well and good -- unless that NT machine Microsoft has running time services is connected to the Global Positioning System.
Why is this a problem? Well, in August of next year, the GPS week counter rolls back to "zero" because of a bug in the GPS system. The Navy is quite clear that they're not planning to fix it, and it it's your responsibility to work around it.
It's not impossible that Microsoft's servers use GPS for the time. GPS is used by many financial institutions to keep time, since it provides a billionth-of-a-second granularity timing mechanism necessary for certain calculations -- and it's practically free.
Suppose Microsoft's time server uses GPS, and further suppose Microsoft forgets to re-write their time software to take into account this bug.
All of a sudden, everyone who gets their time from Microsoft thinks the week is sometimes in the 1970s (or whenever the GPS was first "turned on."
Now, not only are Microsoft's clocks screwed up, so are ours.
That's just one way that dates can screw up between systems. There are a myriad others, each dependant on a specific set of circumstances.
Essentially, anywhere that two computer systems exchange information about dates is potentially a place where corruption can be introduced.
-- "John Smith" (email@example.com), April 26, 1998.
Another example follows:
Suppose I run a payroll processing service. (I don't, but suppose I do.) I process your payroll, manage your various state tax witholdings, etc. but you print the actual checks and balance your own books off of data that I send back to you at the end of each payroll cycle. Here are some of the implications if I send you back dates of 1900 instead of 2000:
1. All of your checks might printed with bad dates and might not be honored by banks.
2. Any databases you have that keep track of your payroll funds might be corrupted by having invalid or incorrect dates entered into them. These include your general ledger, not a place you like to have your postings screwed up.
3. If you and your bank are Y2K complient, at least for check reconciliation purposes, you and your systems might have a hard time reconciling checks that I say were written on 1/7/1900, your system says should have been written on 1/7/2000 and the bank says were cleared during the week of 1/10/2000.
-- Paul Neuhardt (firstname.lastname@example.org), April 27, 1998.