[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ISO 8601 anyone??
On 2001-Apr-19 Brian Hayes <Brian.Hayes@Commerceone.com> wrote in <ebXML-core>: [2001-Apr-20] > Ian, thanks for your thoughtful reply. My original message was to > help generate alternative ideas to ISO 8601, since at Commerce One > we occasonally run into problems with it. The particular problem > that comes to mind are date-time values that have implied values. > For example, we might write on a paper document "April 2001" with > some implied notion of end-of-month or begining-of-month. Or, what > is the standard for encoding a date-time for a contract ending on > 2001 April 30? A date such as 'end of month' does map to a full 'real' date, so I would recommend to use that 'real' date in the data, even though a Calendar look-up of month durations, and of leap year rules, has to be accessed in order to work it out. At least the receiving end will have a real date to work with, rather than the possibility that the receiving party infers something other than your intended meaning when they do the conversion to a 'real' date. If something has to happen by the end of the month, then simply state it fully as '2001-04-30' in the data. There are 'reduced precision' formats (elements removed from the right), and 'truncated' formats (elements removed from the left), in ISO 8601, but I see no reason to use them in most cases. This month is represented by '2001-04', for example. The details of these formats are provided in the ISO 8601 standard. I guess that everyone received a copy from Brian, so should be easy to look up. An example of a problem that can occur: I have recently been working with a customer-facing system that asks, for credit-checking purposes, how long the customer has lived at their present address. The data is entered as YYYY/MM. A later question asks for Date of Birth, as YYYY/MM/DD. For someone who has lived in the same place since they were born; very often an Error is returned that their occupancy exceeds their age. This is because the system take the Occupancy Date of YYYY/MM and expands it to YYYY/MM/01. If a person was born on 1970-06-15, and gives 1970-06 as the Occupancy Date (which is internally expanded to 1970-06-01) then this is the problem - the system thinks they lived there for 2 weeks longer than they were alive. Staff have to be aware of this one, and always put the Occupancy Date as the month after the month of Birth, and they have to do all of this long before the Date of Birth question comes up on the screen. It would have been more useful if the Occupancy Date was taken as the last day of the month, but it is obviously quicker to expand 1970-06 to 1970-06-01 rather than to 1970-06-30, as this needs a calendar look-up function to find the number of days in the month, also taking into account any leap year rules. Not designed by me! >> 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> >> >> [SNIP] > This is a non-issue since the schema would specify the acceptable order of > the elements. Noted, but I wasn't sure that this was the case. >> 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. > Yes, this would be just plain silly. For most of our needs, we are just > transporting data and the display format is left to the application. Noted, but there are many areas where the display/presentation format will be exactly the same as the transported format. We usually display the time exactly as transported (we will always be using same element order), maybe merely doing a Time Zone tweak. Why is it that people want to rearrange the order of dates, and then print them out in an ambiguous format, rather than leaving them in the internationally acceptable way that they are could be being transported? >> Americans shouldn't have too much >> trouble adapting, because the ISO format retains 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. > Clearly the discussion is mixing presentation issues with > data format issues. I do think the issues are linked, even if they aren't directly 'on topic' here. If you want to display the information in full but the information received is truncated, then you have to infer some of it. It is better if full data is transmitted because inferring something can lead to errors. And, repeating what I already said, some formats are acceptable to print 'as is' everywhere in the world, without risk of misinterpretation. Why mess with them? Why take '2001-02-03' and print it as '02/03/01' for example? Anyway I think that topic has now been run dry. It's time to move on to other things. > Attachment Converted: C:\MYDOCU~1\ATTACH~2\ISO8601(Copy2).PDF I do appreciate the thought in sending the copy of the standard, but I have already had a copy of it on my FTP Site for over 3 years. However, I did not appreciate receiving three identical copies of the file: once via the ebXML mailing list, another sent direct to me as a 'Cc:', and a third via ebXML due to some unknown spooling consideration on the ebXML server! Today I was out and about with my Laptop and only a mobile-phone for the Internet connection. Downloading most of my mail took less than 5 minutes, then the three attachments took another hour and ten minutes. Not pleasant. Unfortunately, the standard that was sent (ISO8601:1988) is the old one, which has now been withdrawn by ISO. The new version (ISO8601:2000) was published on 2000-12-21. The web page at: <http://www.iso.ch/cate/d26780.html> refers. The ISO8601:1988 standard was freely available on the Internet, mainly due to its widespread use in tackling the Year 2000 Problem. ISO have not released the ISO8601:2000 standard generally, everyone has to pay for a copy now, either as a PDF file, or on paper. Is there anywhere else that the new ISO8601:2000 version can be easily accessed? It has a lot of new and additional ideas (cf 1988), especially regarding periodic or repeated events. Cheers, Ian. <email@example.com> [2001-04-20] .end
Powered by eList eXpress LLC