RE: ISO 8601 anyone?? - ISO 8601 Attached

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

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 April 30, 2001?

I have some specific comments below...
> > <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?

Yes, optional values are an issue.  That's why something else is needed. In
EDI there are MIGs and some of us in the industry are seeing a need for a
MIG like thing when using XML... Hmm a schema for a schema.

> 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'.

Yes this is a problem and I've seen our application developers searching for
the right answer.


> 
> 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>

This is a non-issue since the schema would specify the acceptable order of
the elements.


> 
> 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'.

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. 
 

> > 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.

Clearly the discussion is mixing presentation issues with data format
issues.

 
> 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.

In for a penny in for a pound.  We are using XML.  IF (big if) it makes
sense to have seperate XML elements for the subelements of a piece of
information, then do so.  If a standard makes it not necessary then don't do
it.  If ISO 8601 sufficently covers 80%-90% of the date-time usage
scenarios, then use it.

ISO8601.pdf