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

[Arthur Ryman]

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 <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
09/05/2012 10:57 AM
Subject:
[oslc-core] Should we transition new specs to use dateTimeStamp instead of 
dateTime
Sent by:
oslc-core-bounces at open-services.net



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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net