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] Updated: (ODATA-314) Please clarify the meaning of filter functions applied to DateTimeOffset values


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

Michael Pizzo updated ODATA-314:
--------------------------------

     Summary: Please clarify the meaning of filter functions applied to DateTimeOffset values  (was: CLONE - Please clarify the meaning of filter functions applied to DateTimeOffset values)
    Proposal: 
Services MUST take offset into account when evaluating the datetime functions year, month, day, hour, and time (I.e., must evaluate in terms of the offset).
Services that cannot preserve offsets MUST fail evaluation of datetime functions for values that are not normalized.

  was:
For reliability, we must do one of the following:

(1) Require that servers preserve zone offsets.

(2) Eliminate filter functions that can become ambiguous/meaningless if servers cannot be guaranteed to preserve zone offsets.

(3) Specify that the values must be normalized to UTC before the functions are applied.

The latter option may be the best we can do for now.



From initial proposal:

For reliability, we must do one of the following:

(1) Require that servers preserve zone offsets.

(2) Eliminate filter functions that can become ambiguous/meaningless if servers cannot be guaranteed to preserve zone offsets.

(3) Specify that the values must be normalized to UTC before the functions are applied.

The latter option may be the best we can do for now.



> 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: [Proposed]
>            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

        


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