Re: ISO 8601 anyone?? And more on Parties.

[g1smd@freeuk.com (Ian Galpin)]

On 2001-Apr-16 William J. Kammerer <wkammerer@foresightcorp.com> wrote in
<ebXML-core>:


[2001-Apr-18]


> Sharon Kadlec says "It's the CONTENT [of dates or times that's
> important], not the format - label it correctly and we'll put it where
> it belongs for our purposes."

> Absolutely!  It's up to the recipient to interpret the normalized
> content - and then display the date, time or dateTime any which way he
> wants.  Therefore, since a dateTime can always be normalized as an ISO
> 8601 extended date-time, there's no need to send along information on
> how to decode it.  As I noted earlier, the spreadsheet catalog has "date
> time.format.text code" defined as "[Using] values from ISO 8601."  There
> are no "codes" in ISO 8601.


Yes, please store in a normalised format... YYYY-MM-DD and HH:MM:SS both
converted to UTC, but please don't print it all out in a different order
upon receipt. What format would be suitable for a US citizen who works in
the European office of a Japanese company? And, what happens when he prints
the data out and then faxes it to the US office, or back to the main HQ in
Japan, or to somewhere in South America... back comes the date ambiguity
problem. This is why there are people (like myself) who keep banging on
about using ISO 8601 from end-to-end in the whole process.


Some anecdotal evidence:

On Web Site  <http://www.useit.com/alertbox/20010401.html>, in the Alertbox
column dated 2001-04-01, "Corporate Websites Get a 'D' in PR," it was noted
(by Jakob Nielsen and Kara Pernice Coyne) that:
        [Thanks to Aron Roberts, University of California]
        [ at Berkeley, for the pointer to this document.  ]
- Providing a perfect site for international users is hard, but the
- basic guidelines for international usability are simple. For
- example, journalists thought that a list of press releases contained
- nothing but old news because it violated one of the most basic
- internationalization guidelines: Use global date formats. When the
- top press release on a site was dated 10-03-2000, a European user-
- naturally assumed that it had been released on the 10th of March and
- concluded that the site was stale. This test session was conducted
- in late 2000, and the press release was in fact dated October 3rd.



> This isn't the same situation as with the EDIFACT C507 DATE/TIME/PERIOD
> composite where the date and time can be transmitted over the wire as
> DDMMYY or DDMMCCYY or CCYYMMDD or YYMMDDHHMMSS, etc. etc. With the
> dateTime XML Schema Data Type, you have no choice:  it must be
> CCYY-MM-DDThh:mm:ss (with optional trailing -  and unambiguous - time
> zone stuff or Z for universal time) - no 'ifs,' 'ands' or 'buts."


EDIFACT is a complete nightmare in that respect. Thankfully that will be
past history soon, and hopefully all those problems and non year-2000
compliant formats will also eventually be consigned to history. Have we
learnt anything from those mistakes?



> Even putting aside the input format considerations, EDIFACT D.E. 2379
> (Date or time or period format code) was used to indicate whether you
> had a Date, a Time, a DateTime, a Period, or a duration, etc. etc. - as
> to say: it was comingling data types. These are handled with separate
> datatypes in XML Schema: viz. a date (e.g., 1999-05-31), a time (e.g.,
> 13:20:00), a dateTime (e.g., 2000-03-04T23:00:00+03), or a duration
> (e.g., P1Y2MT2H), respectively. These are conceptually separate basic
> core components (even dateTime could be considered basic - it needn't be
> merely a date and time aggregated together).


Agreed. Thanks for the useful input.



 Cheers,


 Ian A.N. Galpin.

         Sadly my middle two initials don't repeat, but
         my first three initials do spell my first name ;->


<g1smd@freeuk.com>


[2001-04-18]

.end