From: "Elmar Roberg" To: "Y2 Cinderella" Subject: RE: Discussion around ISO8601:1988 Date sent: Wed, 10 Jun 1998 09:35:40 +0200 WRT to ISO 8601:1988, many people seem to be missing some important points. On superficial reading, it appears that 2-digit centuries are allowed willy-nilly. This is not so. "It is permitted to omit higher order components (truncation) in applications where their presence is implied." (clause 4.5 this clause also refers to clause 5 where the rules for truncation are given.) 5.5.4 states "If higher order components are omitted from the expression following the solidus (i.e. the representation for "end of period"), it shall be assumed that the corresponding components from the "start of period" expression apply (e.g. [if CCYYMM] are omitted by using a dreived representation, the end of the period is in the same year and month as the start of the period);" Since dates in 1999 may be used in conjunction with dates in 2000, this would violate this principle if [CC] is not included. 8601 makes the following points: "This standard is applicable whenever dates and times are included in information interchange." and "This standard does not cover dates and times where words are used in the representation." (clause 1). Before one suggests it only applies to interchange between different organisations, don't, that would be too limited an interpretation. Interchange can be between two componnents in one system, or two systems in one company. We live, as I am sure all would agree, in a global community. Surely one would agree that 1998-03-24, means a lot more than 24 Maart 98, would mean to a citizen of Japan, India, or China. However, the principle of "fit to purpose" must be taken into account. Most technology is not created with the intent that it should still be usable on 12 December 8945. Firstly, we have no idea what the technological world would look like then, nor would the testing and other costs justify the situation. My brother had a Beetle in the 60's that did not have a fuel gauge. He used to carry around stick that he would periodically use to check how much fuel was in the tank. As a safeguard, there was an "emergency tank" that could be used by turning a valve. This was perfectly acceptable at the time. Thus, if I (as a software developer or seller - I am not, but if I were) and my client agree that the software will only be usable in its current form between 1March1900 and 12August2078, then who has the right to make a standard or pass a law that says I may not do so? Even so, if we agree that the software will only work during the period 1900 - 1999, then who will deny me that right. And who will deny my customer the right to buy it? If ISO 8601:1988 is adhered to, correctly, it adequately addresses all of these issues. One should separate the representation (or interface) from the storage of the date (any data, in fact). However, to conform to ISO8601:1988, dates would need to be stored in format so that any date from 0000-01-01 to 9999-12-31 could be stored (clearly not the case). But you cry, "what of BCE dates?" You would be right of course, although one would argue that they are not particularly relevant, just as 10000-01-01 is probably not relevant either, a 4-digit year is all we need. In fact, the IEEE definition for date compliance brings in the point that software should be used in line with its documentation. This I agree with, because it complies with the "fit to purpose" principle of quality. If, as in the case of MS Excel, or any similar product, is not intended to be used as is for calculations involving dates before 1900, then it is the developer's right to create it that way, just as it was the right of SAS to create their software to deal with dates starting on 1 January 4713 BCE (the true "Julian" start date), or Gentia to start on 1582-10-15 (the Lilian date or start of the Gregorian calendar). Just as it is our right to not buy the product if we do not find it "fit to purpose". Our problem is that our rights are either set aside, or diminished, if we discover that the product is not fit to purpose later (especially after the warranty period). By the way, ISO 8601:1988 is available from the SABS in South Africa at a considerably reduced price as ARP 010:1989. I suggest one buys it and actually reads it. regards, elmar > >