RE: ISO 8601 anyone??

[g1smd@freeuk.com (Ian Galpin)]

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.


<g1smd@freeuk.com>


[2001-04-20]

.end