[OASIS Issue Tracker] Updated: (ODATA-314) Please clarify the meaning of filter functions applied to DateTimeOffset values

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

     [ http://tools.oasis-open.org/issues/browse/ODATA-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-314:
-----------------------------

    Environment: [Applied]  (was: [Proposed])

> Please clarify the meaning of filter functions applied to DateTimeOffset values
> -------------------------------------------------------------------------------
>
>                 Key: ODATA-314
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-314
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Task
>          Components: OData Protocol , OData URL Conventions 
>    Affects Versions: V4.0_WD01
>         Environment: [Applied]
>            Reporter: Evan Ireland
>            Assignee: Ralf Handl
>            Priority: Minor
>             Fix For: V4.0_WD01
>
>
> The accepted resolution for ODATA-122 seems to be at odds with protocol spec (2013-03-19) section 10.4.1.2 "Handling of DateTimeOffset Values", which now states:
>   Services SHOULD preserve the offset of Edm.DateTimeOffset values, if at all possible. However, where the underlying storage does not support offset services MAY be forced to normalize the value to some common time zone (i.e. UTC) in which case the result would be returned with that time zone offset.
> Suppose I have a property "myTime" of type DateTimeOffset.
> If I send a filter to the server (excuse the pseudo-filter syntax):
>     day(myTime) eq day(datetimeoffset'2013-03-21T16:59:44+13')
> Now according to protocol spec 10.4.1.2, the server may adjust the RHS literal value to UTC (e.g. due to "storage" of the query expression fragments in memory, or in a database if the server so chooses). If the "day" function is then applied to the adjusted literal value, it won't give the same results as it would have if applied to the value without conversion to UTC.
> If servers are allowed to adjust the offset in DateTimeOffset values to UTC (or another zone), then a client currently has no guarantee about the meaning of filter functions applied to the values.
> --- 
> Original issue text follows:
> ---
> Consider for example the 'day' function applied to a DateTimeOffset.
> Is this supposed to return the 'day' of the value when it is considered as UTC, or the 'day' component as it appears in the original literal value, which implies that the zone offset must be preserved when DateTimeOffset values are propagated?
> If DateTimeOffset values are permitted to be 'normalized' by agents, but are not required to be, then the 'day' function applied to DateTimeOffset value would appear to be meaningless, unless it returns the UTC 'day'.

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