[OASIS Issue Tracker] Issue Comment Edited: (ODATA-121) Please clarify whether agents handling DateTimeOffset must preserve the UTC offset

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Evan Ireland edited comment on ODATA-121 at 9/17/12 6:57 PM:
-------------------------------------------------------------

Ralf requested some clarity for my question, so here goes.

Consider this a sub-task for ODATA-52. Considering the "value space" (not "lexical space") of DateTime(Offset) types:

This question might be best explained by example.

In the "value space" for DateTimeOffset OData types, are the following values identical?

  2012-09-13T15:33:45Z 
  2012-09-13T16:33:45+01:00 

Clearly the values are not identical in the "lexical space", but my question is in regard to the "value space" (semantic) rather than the "lexical space" (syntactic).

For comparison, the "value space" of dateTime in XML Schema Part 2 is defined by reference/equivalence to a computed property "timeOnTimeline", which is a decimal number of seconds from an epoch. Using the XML Schema definition of dateTime, the two values above are identical, and therefore they both have the same canonical lexical representation (which is "2012-09-13T15:33:45Z").

Coming back then to my question for OData DateTimeOffset, is whether the "offset" is significant in the "value space".

Or restated, if we were to formally define the "value space" for DateTimeOffset, would it be:

(1) Similar to XML schema dateTime, by reference/equivalence to a computed decimal property "timeOnTimeline", or

(2) By reference/equivalence to a pair (sinceEpoch:decimal (seconds), zoneOffset:integer (minutes)).

If the answer is (2), which is my preference, then the following values would not be considered identical in the "value space" for DateTimeOffset.

  2012-09-13T15:33:45Z 
  2012-09-13T16:33:45+01:00 

Although the following values would be considered identical as their "sinceEpoch" and "zoneOffset" properties would be equal.

  2012-09-13T15:33:45Z 
  2012-09-13T15:33:45.000Z

The reason I think it is important to have such clarity of the "value space" for DateTimeOffset (and other data types) is that it then becomes clear, based on the CSDL for a service, what agents/proxies can and cannot legitimately do with values without changing the meaning of an OData document.

In particular, it should be perfectly valid for a meta-data-aware agent or proxy to translate a value of some OData-defined type between one lexical representation and another distinct lexical representation within the "lexical space" of the type so long as the value is not changed to another distinct value within the "value space" of the type.


      was (Author: evan.ireland):
    Ralf requested some clarity for my question, so here goes.

Consider this a sub-task for ODDATA-52. Considering the "value space" (not "lexical space") of DateTime(Offset) types:

This question might be best explained by example.

In the "value space" for DateTimeOffset OData types, are the following values identical?

  2012-09-13T15:33:45Z 
  2012-09-13T16:33:45+01:00 

Clearly the values are not identical in the "lexical space", but my question is in regard to the "value space" (semantic) rather than the "lexical space" (syntactic).

For comparison, the "value space" of dateTime in XML Schema Part 2 is defined by reference/equivalence to a computed property "timeOnTimeline", which is a decimal number of seconds from an epoch. Using the XML Schema definition of dateTime, the two values above are identical, and therefore they both have the same canonical lexical representation (which is "2012-09-13T15:33:45Z").

Coming back then to my question for OData DateTimeOffset, is whether the "offset" is significant in the "value space".

Or restated, if we were to formally define the "value space" for DateTimeOffset, would it be:

(1) Similar to XML schema dateTime, by reference/equivalence to a computed decimal property "timeOnTimeline", or

(2) By reference/equivalence to a pair (sinceEpoch:decimal (seconds), zoneOffset:integer (minutes)).

If the answer is (2), which is my preference, then the following values would not be considered identical in the "value space" for DateTimeOffset.

  2012-09-13T15:33:45Z 
  2012-09-13T16:33:45+01:00 

Although the following values would be considered identical as their "sinceEpoch" and "zoneOffset" properties would be equal.

  2012-09-13T15:33:45Z 
  2012-09-13T15:33:45.000Z

The reason I think it is important to have such clarity of the "value space" for DateTimeOffset (and other data types) is that it then becomes clear, based on the CSDL for a service, what agents/proxies can and cannot legitimately do with values without changing the meaning of an OData document.

In particular, it should be perfectly valid for a meta-data-aware agent or proxy to translate a value of some OData-defined type between one lexical representation and another distinct lexical representation within the "lexical space" of the type so long as the value is not changed to another distinct value within the "value space" of the type.

  
> Please clarify whether agents handling DateTimeOffset must preserve the UTC offset
> ----------------------------------------------------------------------------------
>
>                 Key: ODATA-121
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-121
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Task
>          Components: OData CSDL v1.0
>    Affects Versions: WD01
>            Reporter: Evan Ireland
>            Priority: Minor
>             Fix For: WD01
>
>
> The following two DateTimeOffset values identify the same point in time:
> 2012-09-13T15:33:45Z
> 2012-09-13T16:33:45+01:00
> However, it is not clear from the specification if an agent/proxy that is propagating OData documents is required to preserve the actual UTC offset for any given value, or whether it is free to convert between values that represent the same point in time.
> Suggestion: If conversion (preserving the point in time but altering the date/time/offset portions) is permitted, then the data type might more appopriately be named UtcDateTime.

-- 
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