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

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

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

Evan Ireland commented on ODATA-11:
-----------------------------------

I wonder if I adequately described the scenario above:

  var a = new Apppointment(); 
  a.when = dateTime("2007-10-01T10:00:00"); 
  a.where = "WLG"; // IATA code for Wellington, New Zealand 

Suppose I redefine the schema using dateTimeOffset, then in February 2007, I execute this:

  var a = new Apppointment(); 
  a.when = dateTimeOffset("2007-10-01T10:00:00+12:00"); 
  a.where = "WLG"; // IATA code for Wellington, New Zealand 

Now if the interpretation of using dateTimeOffset is that a recipient can treat (and convert) a.when as a UTC value, then it ie equivalent to:

  a.when = dateTimeOffset("2007-09-30T22:00:00Z");

Due to the legislative change (in March 2007, after the appointment was recorded), the start time of daylight savings is now before the appointment (whereas prior to the legislative change, it was after the appointment).

The correct dateTimeOffset value for this apppointment is now (with hindsight):

  a.when = dateTimeOffset("2007-10-01T10:00:00+13:00"); 

which, if we permit the recipient to treat as a UTC value, is equivalent to:

  a.when = dateTimeOffset("2007-09-30T21:00:00Z");

Note how my recipients will now turn up one hour early to the meeting (or if I had retimed my example in 2008, they would miss the meeting).

So clearly, dateTimeOffset is not a reliable way to indicate future events that occur at a well-defined civil time (standard or daylight time, whichever happens to be in effect at the time) in a particular location.

Also dateTimeWithNamedZone is not reliable, since in February I would have thought it appropriate to use 10 a.m. NZST (for 1 October 2007), whereas from March I should have indicated 10 a.m. NZDT (for 1 October 2007).

The non-existent data type dateTimeLocation might be suitable, if Location were defined using UNLOCODE (http://www.unece.org/fileadmin/DAM/cefact/locode/nz.htm).

I accept that for past events, it is reasonable in principle to require the publisher to do the work to indicate a dateTimeOffset.

But for future events, due to the unpredictable behaviour of governments, it is not. A zoneless dateTime (with associated data such as location, which requires recipients to share some business knowledge with the backend system) is in general more well suited to the task.


> 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