Re: FW: Date/Time (WAS: Re: To get things started... Data Formats)

[David Lyon <djlyon@one.net.au>]

All,

Not every country uses European or American date format, so I'm sorry to say
that localised date formats are not workable for a global trading framework.

> The ISO 8601 formats support all these cases.
> Why isn't  '2001-06-04 T 00:22:30 -0500'  clear enough?
> (I spaced it out purely to emphasise the various elements that go into
this
> format). You have the option to use the date and time on their own or
together.

This is the least ambiguious date format that has been discussed here.

I think a lot of time could be wasted trying to come up with something
better.

It would work in every region of the globe that I know of (including
Nigeria) and is globally succinct.

David Lyon


----- Original Message -----
From: Ian Galpin <g1smd@freeuk.com>
To: ebXML core <ebxml-core@lists.ebxml.org>
Cc: Chuck Allen - HR-XML <chucka@hr-xml.org>; Aron Roberts
<aron@socrates.Berkeley.EDU>
Sent: Tuesday, June 05, 2001 7:49 PM
Subject: Re: FW: Date/Time (WAS: Re: To get things started... Data Formats)


> References:
<http://lists.ebxml.org/archives/ebxml-core/200106/msg00006.html>
>
>
>
> On 2001-Jun-04 Chuck Allen <chucka@hr-xml.org> wrote in <ebXML-core>:
>
>
> [2001-Jun-05]
>
>
>
> >  Betty Harvey wrote:
> >> Why not use the ISO 8601 and W3C Date format of CCYY-MM-DD
> >> or 2000-08-18.
>
> Please note that using the term 'CCYY' has always caused problems. This is
> through people calling the 'CC' term, a 'century'. The year '2001' has a
> 'CC' of '20' but is plainly in Century '21' in common parlance. The new
> version of ISO 8601 [published 2000-12-21] has replaced 'CCYY' with just
> 'YYYY'. I am not sure why the various XML Specifications etc, have not
been
> updated to reflect this change. They still refer to the 1988 version, and
a
> draft of the 2000 version. See:  <http://www.iso.ch/cate/d26780.html>  for
> ISO 8601 'Second Edition', published nearly 6 months ago.
>
>
>
> > The date, time and dateTime data types provided in the
> > Schema Recommendation are an obvious place to start - but
> > there can still be a lot of design issues depending
> > on what you need to support.
>
> The W3C Schema supports a Date on its own, a Time on its own, or a Date
and
> Time together, any of which can be in the Local Time Zone, a stated
> (numerical format) Time Zone, or in the UTC (usually stated as 'Z') Time
> Zone. That should cover every permutation required. Or is there something
> special that I have missed?
>
> ISO 8601 has some other date formats that count days within the year, or
> count weeks within the year (with the first Thursday of the Year being
> within the first week of the year), and days within the week (with Monday
as
> 1, and Sunday as 7). So today is  2001-06-05  or  2001-156  or
2001-W23-2.
> XML seems to have only picked up on the first ISO format, not the other
two.
> There are times when the others are more useful.
>
>
>
> > The HR-XML Consortium's Cross Process Workgroup has begun
> > taking a look at various approaches for capturing date
> > and time information within XML schema. Some of the
> > scenarios we need to support in the human resource
> > management space are particularly complex. The
> > preciseness of the date/time value is often dependent
> > on the business context. For instance, a hire date can
> > often be captured as date value, the exact time a person
> > is hired is not important to most systems. An incident
> > date requires more precision. Most systems require the
> > date and time an incident took place.
>
> The ISO 8601 formats support all these cases.
> Why isn't  '2001-06-04 T 00:22:30 -0500'  clear enough?
> (I spaced it out purely to emphasise the various elements that go into
this
> format). You have the option to use the date and time on their own or
together.
>
>
>
> > Also, in the case
> > of an incident, the time zone may be required. Eleven
> > o'clock in the evening on July 31 in Washington DC, is
> > four o'clock in the morning on August 1 in London. This
> > could mean a difference in coverage for the employee.
>
> ISO 8601 supports time zones. They are stated as the difference from UTC,
so
> you avoid the problem of what a Time Zone like IST, or LPT may stand for,
> and what its numerical value is supposed to be... ISO 8601 uses formats
like
> '-0700' and '+1130' etc, which are so much more clear. It is important to
> use all four digits for the Time Zone, as not all time zones are aligned a
> whole number of hours offset from UTC. There are several on 15, 30, and 45
> minute offsets.
>
>
>
> > Anyone interested in this work, may want to review
> > these drafts:
> > <http://docs.hr-xml.org/HR-XMLDateTimeDataTypes2001-05-23.pdf>
> > <http://docs.hr-xml.org/HR-XMLEffectiveDating06-03-2001.pdf>
> > These are obviously snap shots of work-in-progress documents.
>
> I will review those and contact you directly. I already had a quick scan
and
> found a number of issues.
>
> The first very obvious point is whether the 'Effective Dating' document
was
> produced on June 03 or on 6th March of this year! Not an effective method
> for dating your document!
>
>
>
> > These are obviously snap shots of work-in-progress documents.
> > As such, they do not necessarily represent any sort of
> > consensus opinion of Consortium members. Feel free to
> > comment - or contact me if you are interested in participating
> > in this work.
>
> These documents are dated, as part of the filename. Without knowing the
> actual date of the latest revision, it will not be possible to access the
> latest version directly, unless you post the static web site address of
the
> page they can be downloaded from. Alternatively, you could post each
version
> with a dated filename, and then have a second copy with a 'generic' name
> like 'HR-XML-EffectiveDatingLatestVersion.pdf' for the current version.
> Otherwise we will never be able to find the latest version.
>
>
>
> [SNIP... No Block Quoted Material]
>
>
>
>
> On 2001-May-31 (Thu) David Lyon wrote:
>
>
> >> > My recommendation will be that these SME XML's must converge a lot of
> >> > things.  For example here are three date formats and address formats
used
> >> > by the three companies.
>
> >> > IntAcct
> >> >      <datecreated>
> >> >         <year>2000</year>
> >> >         <month>8</month>
> >> >         <day>18</day>
> >> >     </datecreated>
>
> >> This is such a cumbersome mechanism. Both to code, as well as for the
> >> business user to understand.
>
> There may be times when a date has to be broken down into further
elements,
> but breaking up ISO 8601 syntax is even easier to do than this, and is
much
> more 'byte-efficient'. The first four characters are the Year... etc; or
you
> can parse to the '-', 'T' and ':' separators.
>
>
>
> >> Here in Australia we've been using an approach which simplifies this
to:
>
> >>  datecreated@="18-July-2000"
>
> >> It's much easier to parse, and is far less prone to error than the
first
> >> example.
>
> You can parse it, but it is not numerically computer sortable, without
> converting it to a fully numeric date or by providing a look up table of
> months. Your software may also have to cope with 'July', 'JULY', 'july',
> 'juLY' as well as 'Jul', 'JUL', and 'jul' etc, and there would be the
> temptation for some to use the Month Name in foreign languages as well.
> Surely a wholly numerical solution would be better. A large proportion of
> the world does NOT speak English.
>
>
>
> >> <Order Item List>
> >>   <Order Item>
> >>     Code&="290"
> >>     Name&="Female Dormitory Bed"
> >>     Description&="Arriving Mon 21-05-01 2:12:51 PM, Departing Tue
22-05-01."
> >>     Quantity#=2
> >>     Rate$=90
> >>     Tax$=0
> >>     Amount$=180
> >>   </Order Item>
> >> </Order Item List>
>
> After all that was written about the use of Two Digit Year representations
> and the Year 2000 Problem, I am horrified to find people still suggesting
> date formats like this, and what is it about AM/PM that the US and a very
> few other places has to keep hold of: 12AM, is that midnight or midday?
> 00:00 and 12:00 solve the problem. In Europe, most people are happy with
> 24-hour format time. Travel timetables have already used it for several
> decades. When will the rest of the world catch up with this simple idea?
The
> aboce format incudes redundant information... 'Mon 21-05-01'. What if
> 2001-05-21 were not a Monday? Should receiving software check the day
value,
> or just accept it as is?
>
>
> What is wrong with '2001-06-04' as a date?  It's parsable, sortable, has
> only ONE valid meaning (wheras '04/06/01' or '04/06/2001' has a different
> meaning on the two sides of the Atlantic), always of fixed number and
> position of digits, due to the use of leading zeroes, and is far easier to
> program. If needed, when the date arrives on your system, you can
translate
> it to another form, but even here you can retain the same clear Y-M-D
> element order, and just print the month as a word in the local language.
See
> <http://umbra.nascom.nasa.gov/> for a web site that already does this
> (though the local language is, of course, English).
>
>
>
> [SNIP... No Block Quoted Material]
>
>
>
>
> On 2001-May-31 (Thu) Todd Boyle wrote(>):
>
>
> >> >    <postDate>01/14/2001</postDate>
>
> You have got to be kidding. That format does not have human
intelligibility
> for half the planet for the first 12 days of each month. Why, after being
> around for over 30 years, is the ISO date format not the automatic choice?
>
>
>
> [SNIP... No Block Quoted Material]    Hmm, a reply of 8K to an 18K
message!
>
>
>
>
> Cheers,
>
> Ian.
>
>
> <g1smd@freeuk.com>
>
>
> [2001-06-05]
>
> .end
>
>
>