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

[g1smd@freeuk.com (Ian Galpin)]

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