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

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Folks:

I agree with Chuck's statements. In SOX, the XML schema language used as the
primary implementation of xCBL inside of Commerce One's products, the *only*
allowable date and time formats are an unrestricted ISO 8601. Nothing else
is allowed. This is great, except that - as Chuck points out - it does not
require *enough* for guaranteeing that global trade scenarios, for example,
will have the information they need (can't require the time zone), and that
periods/durations are lacking (we handle these with more complex structures,
and not as part of this datatype). Effective dates, too, are something that
uses a primitive datetime as part of a more complex structure (we have found
that effectivity is used different ways in different industries, and that
one data structure won't always work. Of course, if you add a bit of
context...)

Cheers,

Arofan Gregory



-----Original Message-----
From: Chuck Allen - HR-XML [mailto:chucka@hr-xml.org]
Sent: Tuesday, June 05, 2001 2:13 PM
To: ebxml-core@lists.ebxml.org
Subject: RE: FW: Date/Time (WAS: Re: To get things started... Data
Format s)


ISO 8601 is absolutely the way to represent dates/time 
-- we believe this even if we aren't as careful as NASA in 
showing this on the press release page of our website ;-)

HR-XML is exploring certain data types based on 8601 
representations of date and time. Why bother with the data types?
For certain types of transactions, we want to be able to set 
constraints rather than merely allow any variety of compliant
8601 representation. 

As our draft documents point out, a high degree of precision is 
often required in HR transactions. In transactions with a partner
or third party that may effect employees' pay and benefits
(and the employer's tax and/or reporting obligations to 
governmental agencies) there are many instances where you
might want to have time and date information submitted
in a very exact and predicable way. For example, you might 
want to require that trading partners include the time zone 
indicator. As I understand it, 8601 allows you to optionally
append a time-zone indicator, but doesn't give you a 
mechanism to require it - This is what you can do with schema and 
data types.

I guess the other way that 8601 isn't sufficient on its own
is in expressing periods or durations. Again, if you take a
look through those rough, non-consensus, off-the-cuff,
please-overlook-the-stupid-typo drafts, you will see that
the workgroup is very much interested in standardizing ways
to communicate period and duration information.

I'm not sure whether ebXML core components needs to address
what in HR-system speak we call "effective dating". However,
I was interested in sharing the documents to give other ebXML
participants an idea of the type of transactions and 
requirements within the HR domain. My guess is
that while our docs may give the HR spin, there are likely
a lot of other vertical and other horizontal domains that
share some of the same type of requirements.

Best Regards,

Chuck Allen
Director, HR-XML Consortium, Inc.