[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: Date/Time (WAS: Re: To get things started... Data Format s)
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:firstname.lastname@example.org] Sent: Tuesday, June 05, 2001 2:13 PM To: email@example.com 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.
Powered by eList eXpress LLC