[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ISO 8601 anyone??
On 2001-Apr-16 Brian Hayes <Brian.Hayes@Commerceone.com> wrote in <ebXML-core>: [2001-Apr-18] > IMHO, date and time should follow ISO8601 as documented; or deviate by > breaking out the date time parts, naturally, parts would need to be > optional.. > <datetime> > <year>...</year> > <month>...</month> > <day>...</day> > <hour>...</hour> > <minute>...</minute> > <second>...</second> > ...plus other ISO8601 elements... > </datetime> If parts are optional, then I can see potential problems. If the receiving system needs a particular element, and it isn't there, should it infer it? The rules would need to be carefully thought out and implemented. An order is placed in the US on the afternoon of 2001-12-31, but the date format transmitted does not include the year. The receiving system, in Australia (already in 'Jan-01' date zone), sets the year as 'current', so writes the order to the database as 2002-12-31. Maybe, maybe not? It is the sort of behaviour that might be missed in initial testing of a system, but is not too far away from the sort of 'bad logic' that was the 'Year 2000 Problem'. If information is broken down this much, then I can also forsee that US programmers would then arrange the data thus: <datetime> <month>...</month> <day>...</day> <year>...</year> <hour>...</hour> <minute>...</minute> <second>...</second> ...plus other elements... </datetime> whilst Europeans would set it to: <datetime> <hour>...</hour> <minute>...</minute> <second>...</second> <day>...</day> <month>...</month> <year>...</year> ...plus other elements... </datetime> I know that it doesn't seem really important, but they would probably do this so that they could retain printing the date as '12/31/2001' in the US and as '31-12-2001' in Europe, without giving the processing too much of an extra overhead. In my opinion, that would be a mistake, because once the data hits a piece of paper, then the date is fixed in one particuar format, and if that paper travels to a different country then there is a possibility that the date gets misread (e.g. a date like 03/02/2001). Markup does not help after the date has been printed out. If it gets printed, then my opinion is to still retain the Y-M-D ordering in the printout. Although not within the terms of what we are discussing here, I would prefer to see the same format (ISO 8601 of course) used as input, and in all storage, transmission, display and final printout. That way there is going to be less chance that the data gets scrambled or misinterpreted either by machine or by human anywhere within the chain. I would hope that by leaving the date as a complete date, and time as a complete time, rather then breaking them down further, that this would be more likely to lead to people into just displaying and printing the data exactly as transmitted, rather than trying to reformat it into other element orders. There is a much wider campaign going on to get people to think in terms of Year-Month-Day for everything they do. To most people in Asia, Scandinavia, and Eastern Europe this idea is not new. Many other people have already done this for a very long time. In various sciences, such as Astronomy, Y-M-D normalised to UTC (GMT as was) has been the standard way of doing things for about 200 years. The Year 2000 Problem was caused by the use of a two-digit year. That was fixed by using all four digits. However, few people bothered to address the US or Europe format (dd/mm or mm/dd) ambiguity present in a date like 03/02/01, even though ISO 8601 has been around for many years. Most of the world has signed up, but most people are just being lazy in not using it. I get angry when I see adverts for events or meetings called for 05/06 or 05/06/01. I am pleased to see so many new computer protocols are adopting it. Brian Hayes <Brian.Hayes@Commerceone.com> wrote: > Or > < datetime> > <date>...</date> > <time>...</time> > </datetime> There is another possibility: <datetime> <date.USA>mm-dd-yyyy</date.USA> [Please forgive the exact or <date.Eur>dd-mm-yyyy</date.Eur> [syntax. I know there are or <date.ISO>yyyy-mm-dd</date.ISO> [several ways of doing it. <time>...</time> [I have no favour over </datetime> [dotted notation. I hope no-one ever goes down that road, because it adds too much complexity to the processing, and again, people will misread the information once the data gets printed. I am all in favour of using just one unambiguous format (and the ISO 'yyyy-mm-dd' gets my vote), and then using it 'end to end'. Isn't it strange that everyone writes time as 'hh:mm' or 'hh:mm:ss'. No one uses 'mm:hh' or 'ss:hh:mm' for times. Why is it that just date that has all the hassle? Since time is stated largest element first, then it is logical that we also do this with date. > Gee, with schema extensions, we could extend datetime to support > nanoseconds!. For some applications, users may wish to do so, but ISO 8601 already allows you to specify a decimal fraction on the end of any time element anyway; so the datetime '1999-12-31T23:59:59.999999999' is still completely valid (as far as the ISO standard is concerned). Am I right in believing that some banks time-stamp some very large transactions to the second, possibly milli-second (using GPS time) as the money may be attracting interest measured in thousands of USD [ISO 4217!!], or equivalent, per minute? On 2001-Apr-16 William J. Kammerer <firstname.lastname@example.org> wrote in <ebXML-core>: > It's clear Ian Galpin really, really likes ISO 8601, and wants the rest > of us to use it everywhere, not just in the XML instances of core > components. I'm sympathetic - but it does take a lot of conditioning for > those Americans to start doing it right. Thanks for the support! Americans shouldn't have too much trouble adapting, because the ISO format reatins the old US 'mm/dd' date ordering. The new format merely makes the year (preferably) as four-digits, whilst moving it to the front. It changes 'MM/DD/yy' to 'yyyy-MM-DD'. It then means the same to every person on the planet. No more misreading it. Have a look at <http://umbra.nascom.nasa.gov/> for a NASA Web Site that uses Year-Month-Day for absolutely everything. Looks strange at first, but you'll soon get used to it. > Most people do want to follow > standards if they're easy to understand; it helps that XML Schema > includes a datatype for dateTime which enforces the ISO 8601 extended > format CCYY-MM-DDThh:mm:ss. And it would be a really rare case where we > would have to break out the individual year, month, day, hour minute and > second, as Brian Hayes demonstrated. Breaking it down seems such a waste. It pushes up the character overhead in the tags massively. Don't forget that all this data structure we are defining has to be transmitted through networks, and then stored somewhere. The bigger the data, then the longer the tranfer time, and the more computer space will be used up. Corporations could end up having to process Terabytes per day. > It should please Ian to know that no one is fighting a standard DateTime > format, though it's still not clear Core Components "gets it" with > respect to the date time.type in the catalog - it STILL has a date > time.format.text code which is defined as "[Using] values from ISO > 8601," whatever that means - there are no "format text codes" in ISO > 8601. Hopefully, we'll eventually end up with some core component, > manifested as an ISO 8601 extended format, which everyone feels > compelled to adopt - including RosettaNet which now uses the non > schema-compliant basic format without the dashes, e.g., > 20001121T145200.000Z. Have you got a pointer to that document? I am glad that many people are in favour of this format, but it would be nice to see that people use it in other contexts, as it will show that they really are thinking about what they are doing. No more documents dated '04/05' please! > But ebXML Core Components really needs a lot more than just a dateTime > component. It's still struggling to get a Party core component off the > ground! I agree, but enough has been said about that by others who have far more knowledge than myself. Much of my background is from a scientific side, not from 'business processes', but Astronomers dealing with AIML (Astronomical Instrument Markup Language), and others, have had the same debates about DateTime. They are happy with Y-M-D, but should it be broken down, or stated as one element? I haven't seen a final decision. A further problem is that Astronomers don't just use dates in the Gregorian calendar as Y-M-D. They also use Year and Ordinal Day of Year (eg 2000-365), but luckily that one is also defined in ISO 8601. The other one they use is not. That is the Julian Day Number, which is simply a count of days since BC 4713-Jan-01 in the Proleptic Julian Calendar. It's a useful format if you know that something orbits in 17239 days, and was last here on Julian Day number JD2430765; otherwise the processing to find the return date is horrendous. To many people, a date is just a date, no big deal, but until you actually start to read about the history of dates, calendars, and date formats you have no idea of the complications and problems that there have been over the centuries. Have we learnt anything from that? I notice that all discussions of date here have always assumed usage of the Gregorian Calendar without question. Are there other people on the other side of the world devising systems based on one of the many other calendar systems still in common usage? If so, there are problems looming... Cheers, Ian. <email@example.com> [2001-04-18] .end
Powered by eList eXpress LLC