[oslc-core] Should we transition new specs to use dateTimeStamp instead of dateTime

[John Arwe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120905/50ba67d4/attachment-0003.html>