-
Type:
Task
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: Protocol, URL Conventions
-
Labels:None
-
Environment:
[Applied]
-
Proposal:
-
Resolution:
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'.
| Field | Original Value | New Value |
|---|---|---|
| Component/s | OData Protocol [ 10267 ] | |
| Proposal |
DateTime functions MUST be evaluated in the timezone of the datetime value. So, for example, 'day" would return the day in the specified timezone, not normalized UTC. Accepted: https://www.oasis-open.org/committees/download.php/48346/odata-meeting-26_on-20130221-minutes.html#odata-122 |
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. |
| Resolution |
https://www.oasis-open.org/committees/download.php/48379/odata-core-v4.0-wd01-part2-url-conventions-2013-02-25-RH.doc Accepted: https://www.oasis-open.org/committees/download.php/48549/odata-meeting-29_on-20130314-minutes.html#odata-122 |
|
| Description |
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'. |
The accepted resolution for 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'. |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| Summary | CLONE -Please clarify the meaning of filter functions applied to DateTimeOffset values | CLONE - Please clarify the meaning of filter functions applied to DateTimeOffset values |
| Status | New [ 10000 ] | Open [ 1 ] |
| 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. |
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. |
| Summary | CLONE - Please clarify the meaning of filter functions applied to DateTimeOffset values | Please clarify the meaning of filter functions applied to DateTimeOffset values |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| 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. |
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. Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-314 |
| Environment | [Proposed] | [Applied] |
Accepted on 2013-06-20
| Status | Applied [ 10002 ] | Closed [ 6 ] |
| Assignee | Ralf Handl [ ralfhandl ] | Ralf Handl [ handl ] |
| Reporter | Evan Ireland [ evan.ireland ] | Evan Ireland [ evan.ireland.2 ] |
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.