RE: FW: Date/Time (WAS: Re: To get things started... Data Format s)

["COOPER,STEPHENIE (HP-PaloAlto,ex1)" <stephenie_cooper@hp.com>]

Hello.

Aye, y'aye y'aye.  Why is this such a problem that it's not solved after 18+
months of effort?

Air traffic control long ago realized that using localised lingo was not
going to work.  People's lives were at stake.  So English was chosen as the
international language, semantics were agreed upon, phrases were agreed upon
(mostly based on American English).  Pilots in all countries are required to
learn and use this English.  Even a plane flying from Neiafu, Tonga to
Nuku'alofo, Tonga is required to communicate with air traffic control in
English.

Okay, so lives are not at stake in B2B (or are they)?  There's a nice
summary of ISO 8601 at http://www.cl.cam.ac.uk/~mgk25/iso-time.html.

It says, for example:

	Date
	The international standard date notation is 

	YYYY-MM-DD

It also says:

	The hyphens can be omitted if compactness of the representation is
more important 
	than human readability, for example as in 

	19950204

Works for me.

	Time of Day
	The international standard notation for the time of day is 

	hh:mm:ss

Hey, that works, too.

I'm content to let solution providers deal with localisation.

My base of SME suppliers using our web solution, who are from U.S., U.K.,
France, China, Singapore, Mexico, etc. have been able to adjust quite
nicely.  We've never had parts shipped on the wrong date because of the date
representation.

Regards,
Steph.
>^,,^<    >^,,^<     >^,,^<     >^,,^<
Stephenie R. Cooper
eBusiness Development Engineer
Supply Chain Information Technology
Hewlett-Packard Company
1501 Page Mill Rd. M/S 4L-5
Palo Alto, CA 94304
(650) 857-6970
mailto:stephenie_cooper@hp.com
www.hp.com

Standards Convergence Manager
RosettaNet
www.rosettanet.org
mailto:stephenie.cooper@rosettanet.org

Member, Board of Directors
Electronics Industry Data Exchange Association (EIDX)
www.eidx.org
>^,,^<    >^,,^<     >^,,^<     >^,,^<

-----Original Message-----
From: David Lyon [mailto:djlyon@one.net.au]
Sent: Tuesday, June 05, 2001 6:20 AM
To: ebxml-core@lists.ebxml.org
Subject: Re: FW: Date/Time (WAS: Re: To get things started... Data
Formats)


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