John, Rather than change the datatype, can't we simply require the use of TZ or at least make it a best practice?
Regards, ___________________________________________________________________________ Arthur Ryman DE, Chief Architect, Reporting & Portfolio Strategy and Management IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: John Arwe <[email protected]> To: [email protected] Date: 09/05/2012 10:57 AM Subject: [oslc-core] Should we transition new specs to use dateTimeStamp instead of dateTime Sent by: [email protected] I notice that Core 2.0 uses xsd:dateTime [1] which leaves the timezone component of the lexical representation as optional. We should consider moving to xsd:dateTimeStamp [2] for new definitions, which requires the timezone; it was added in Schema 1.1 which is now a Rec. Certainly agree there would be migration issues for existing vocabulary; hence "consider" and "for new definitions". Considerations: - dateTime's that lack timezones are often (but not always) still comparable to those that have timezones. They are "partially ordered" essentially based on how far apart they are; within +/- 14 hours, no definitive ordering can be established. [1] - if your clients can be in different time zones than the server, and updating (clients supplying as input) datetimes themselves, your code is semantically broken already and in a fairly hard to tell way - if you have clients that look across providers they're more vulnerable (more likely to be talking to servers running in different timezones). - At least some Tivoli implementations now in beta reject requests whose times omit timezone qualifiers Many people believe there is a defined default behavior when TZ is missing, e.g. +00 (GMT). From [1]: All timezoned times are Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time"). Other timezones indicated in lexical representations are converted to UTC during conversion of literals to values. "Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; [1] section 3.2.7.4 Order relation on dateTime gives several examples where comparisons between values are indeterminate (because one has a tz, the other does not, and they differ by < 14 hours), e.g. > For example, there is no determinate ordering between (a) 2000-01-20T12:00:00 and (b) 2000-01-20T12:00:00Z. [1] http://www.w3.org/TR/xmlschema-2/#dateTime [2] http://www.w3.org/TR/xmlschema11-2/#dateTimeStamp Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
