OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Issue Comment Edited: (ODATA-11) date/time values without explicit time zones need further investigation


    [ http://tools.oasis-open.org/issues/browse/ODATA-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31142#action_31142 ] 

Evan Ireland edited comment on ODATA-11 at 9/12/12 1:35 AM:
------------------------------------------------------------

Since my last comment, I have done some more research and consulted with other colleagues, in particular one of the Sybase architects who is involved with the Sybase JDBC API and is author of the TDS (Tabular Data Stream) protocol specification.

In particular, focusing on the question whether it is reasonable for OData to have a single "DateTime" type (with mandatory zone offset), rather than two types (one with zone offset, and one without zone offset). I think that we have already established that an "ambiguous" type with optional zone offset (like XML Schema dateTime) should be avoided.

When we have zoneless EIS data value that is accessed via OData, having a single "DateTime" type (with mandatory zone offset) would require us to add a zone offset (e.g. "Z") to the zoneless value. Unfortunately, this misrepresents the nature or precision of the EIS data value.
It is akin to adding unidentified insignificant digits to a numeric value (see http://en.wikipedia.org/wiki/Significant_figures#Identifying_significant_figures).
It also does not provide sufficient clarity to agents (e.g. software) which propagate the value that they should preserve the fields (e.g. year/month/day/hour/minute/second) as the values are passed between tiers, instead some agents may consider that it is acceptable to treat such values as precise instants in time.

Note that in Sybase Unwired Platform, we currently only support zoneless dateTime values. When we receive a zoned value from an EIS, we have defined some rules to map that into a zoneless value. It is significant that in this case we may "lose" precision (if sufficient compensating actions are not taken by client applications), but we will never misrepresent a value as having more precision than it really has. I mention this not to suggest that OData should have only a zoneless DateTime type, but just to highlight the difference between dropping precision and misrepresenting a value by adding apparent precision.

We should seriously consider aligning with HTML5, which clearly defines a number of data types for date and time, in what looks to be more considered fashion than XML Schema Part 2: Datatypes.

"date" http://www.w3.org/TR/html5/common-microsyntaxes.html#dates
"time" http://www.w3.org/TR/html5/common-microsyntaxes.html#times
"local date and time" http://www.w3.org/TR/html5/common-microsyntaxes.html#local-dates-and-times
"global date and time" http://www.w3.org/TR/html5/common-microsyntaxes.html#global-dates-and-times
"duration" http://www.w3.org/TR/html5/common-microsyntaxes.html#durations

Note HTML5 does not permit durations with "M" (month) or "Y" (year) as they are not precise in the number of seconds.

HTML5 also defines month (year and month), yearless date, and week, although for OData we might choose to skip those as they are somewhat esoteric.


      was (Author: evan.ireland):
    Since my last comment, I have done some more research and consulted with other colleagues, in particular one of the Sybase architects who is involved with the Sybase JDBC API and is author of the TDS (Tabular Data Stream) protocol specification.

In particular, focusing on the question whether it is reasonable for OData to have a single "DateTime" type (with mandatory zone offset), rather than two types (one with zone offset, and one without zone offset). I think that we have already established that an "ambiguous" type with optional zone offset (like XML Schema dateTime) should be avoided.

When we have zoneless EIS data value that is accessed via OData, having a single "DateTime" type (with mandatory zone offset) would require us to add a zone offset (e.g. "Z") to the zoneless value. Unfortunately, this misrepresents the nature or precision of the EIS data value.
It is akin to adding unidentified insignificant digits to a numeric value (see http://en.wikipedia.org/wiki/Significant_figures#Identifying_significant_figures).
It also does not provide sufficient clarity to agents (e.g. software) which propagate the value that they should preserve the fields (e.g. year/month/day/hour/minute/second) as the values are passed between tiers, instead some agents may consider that it is acceptable to treat such values as precise instants in time.

Note that in Sybase Unwired Platform, we currently only support zoneless dateTime values. When we receive a zoned value from an EIS, we have defined some rules to map that into a zoneless value. It is significant that in this case we may "lose" precision (if sufficient compensating actions are not taken by client applications), but we will never misrepresent a value as having more precision than it really has. I mention this not to suggest that OData should have only a zoneless DateTime type, but just to highlight the difference between dropping precision and adding misrepresenting a value by adding apparent precision.

We should seriously consider aligning with HTML5, which clearly defines a number of data types for date and time, in what looks to be more considered fashion than XML Schema Part 2: Datatypes.

"date" http://www.w3.org/TR/html5/common-microsyntaxes.html#dates
"time" http://www.w3.org/TR/html5/common-microsyntaxes.html#times
"local date and time" http://www.w3.org/TR/html5/common-microsyntaxes.html#local-dates-and-times
"global date and time" http://www.w3.org/TR/html5/common-microsyntaxes.html#global-dates-and-times
"duration" http://www.w3.org/TR/html5/common-microsyntaxes.html#durations

Note HTML5 does not permit durations with "M" (month) or "Y" (year) as they are not precise in the number of seconds.

HTML5 also defines month (year and month), yearless date, and week, although for OData we might choose to skip those as they are somewhat esoteric.

  
> date/time values without explicit time zones need further investigation
> -----------------------------------------------------------------------
>
>                 Key: ODATA-11
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-11
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL v1.0
>            Reporter: Andrew Eisenberg
>            Assignee: Michael Pizzo
>
> The reflection in OData of date/time values without explicit time zones needs further investigation.
> One way in which this issue manifests itself is in the comparison of a datetime value with a timezone to a datetime value without a timezone.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]