According to what I have read, there is no agreed upon universal standard as to how the 00 date will be expressed in computer code. Not being at all familiar with computer programming, my question is: Is there a universal standard now which allows variously programmed computers to recognize each others dating methods? If there hasn't been any standard for the two digit programs until now, why should it matter in the new format for 2,000? Perhaps I don't understand what the issue is as far as compliance compatibility. Thanks in advance.

-- Robert (worldpage@aol.com), October 09, 1999

Answers

The problem is your use of the word "universal". What's essential is "pair-wise" standards between system A and system B, if they exchange date-related information.

Within an individual company, there may well be a common standard for dates; that way, the programmers and analysts don't have to go through a negotiation session every time they build a new system for internal use.

And in industry, it's common for the 800-pound gorillas (e.g., General Motors, or the U.S. Defense Department) to promulgate a standard, and simply REQUIRE all of their contractors and vendors to follow it.

But just as there is no universal standard for AC plugs (have you ever traveled to Europe and tried to remember which adaptor(s) to bring along?), there is no world-wide standard for representation of dates. Aside from the annoying technical details that are involved, we mustn't forget that the Japanese and the Arab countries have entirely different calendars, with a different starting point for "year 0."

Ed

-- Ed Yourdon (ed@yourdon.com), October 09, 1999.

It really doesn't matter how any one system on any one platform holds dates. It never did. What DOES matter is that data transfer adheres to a previously agreed protocol. The protocol MUST be agreed upon before data transfer and data acceptance. When one end of the data transfer learns that the agreed-upon scheme must be changed, the other folks MUST be informed and the scheme coordinated. This has always been true and has encompassed much more than dates.

-- Anita (notgiving@anymore.com), October 09, 1999.

Yeah, Anita is absolutely on target.

Like, suppose you wanted to send a space probe to Mars, and you needed to tell the probe how far it was. You might tell the probe that its 128432394400332723949448393484 units from Earth. But of course you would have to make sure that all the components that needed to know this were in sync with what the units represented. Otherwise, one component might think that it was inches, but another might think it was centimeters, and the entire mission would completely fail and everyone involved would look absolutely stupid.

Of course, the above is just a silly, far fetched example that I made up, nothing like that could ever happen in real life. But, hopefully, it got the point across.

-- King of Spain (madrid@aol.cum), October 09, 1999.

Wow, but do the systems mudwrestle?

-- Teeny Bopper (Bee@bop.alulu), October 09, 1999.

King:

If you believe that what I stated is true, why would you believe (and forgive my assumption that you believe) that suddenly unremediated systems would begin sending remediated systems information in a form outside of the updated agreed-upon protocol, thereby causing a collapse of the receiving system?

-- Anita (notgiving@anymore.com), October 09, 1999.

If you are talking about the Standards bodies, there is no one accepted standard. There are three. One is primarily European, the other two are competing US standards.

But the other posters are right. Regardless of what some standards body says, if I send YYYYMMDD and the other system, program, or hardware reads it as YYYYMMDD everything is spiffy, because there isn't any 'v-chip' to say 'Whoops! You failed to follow the standard.' and shut my systems down.

Of course, all of this is pretty much moot. I was working on a couple of systems for remediation earlier this year, and two organizations within the same COMPANY had requirements with different date representations and even after I had spent an hour meeting with each of them individually, and another one collectively, they STILL didn't get it. And when I respectfully declined to write the silly things, they simply assigned the two systems to two different engineers, neither of whom was given the requirements or specs for the receiving system, and they happily coded up exactly what was called for. And of course, neither one works, and nobody can understand why.

-- just another (another@engineer.com), October 09, 1999.

Anita: This is a trick question, right? You are actually being sarcastic, right?? Well, OK, here goes anyway: BECAUSE THE SYSTEMS WERE NEVER TESTED AS ONE COHESIVE "SYSTEM AS SYSTEMS"!!!!!

Teeny Bopper: 1) Are you 18 or older? 2) If the answer to 1) is YES, do you like, or think that you might like, to mudwrestle?

-- King of Spain (madrid@aol.cum), October 10, 1999.

I agree with King of Spain.

That System Y and System Z have a compliant interface does not preclude System Y from sending erroneous data (though syntactically correct) to System Z. What System Y sends System Z might be derived from the former's interface with System X, which it in turn might have derived from its interface with System W. Here's the flow.

System W => System X => System Y => System Z

Suppose System Z is identified (correctly) as mission critical, which brings about changes in its interfaces, including its interface with System Y. System Y, though not perceived as mission critical, enhances its interface with System X to make that interface compliant. System X and System W, neither judged to be mission critical, exchange data using a non-compliant interface, which they do not change.

From a local perspective, everything's fine. Folks working on System X realize it's getting non-compliant data from System W, but find this acceptable since System Y has not been designated mission critical. Folks working on System Y see compliant input from System X and compliant output to System Z, so again, do not perceive a problem.

Perceiving the problem prior to deployment requires understanding the entire flow from W to Z, a breadth of expertise that few people have the time or the inclination to acquire. Moreover, someone capable of recognizing the problem is unlikely to exert any direct influence over funding issues. If the problem eventually caused trouble at System Z, diagnosing the cause would not be easy.

This reveals the difficulties in designating a system as not mission critical. If a system either directly or indirectly feeds a mission critical system, then in at least that respect, the former is also mission critical.

-- David L (bumpkin@dnet.net), October 10, 1999.

The date standard is defined in ISO 8601.

-- PNG (png@gol.com), October 10, 1999.