Re: ISO 8601 anyone??

[g1smd@freeuk.com (Ian Galpin)]

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 <wkammerer@foresightcorp.com> 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.


<g1smd@freeuk.com>


[2001-04-18]

.end