-
Type:
Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: URL Conventions
-
Labels:None
-
Environment:
[Proposed]
-
Proposal:
-
Resolution:
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 |
|---|---|---|
| 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. |
|
| Environment | [Proposed] |
| 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. |
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 |
| Status | New [ 10000 ] | Open [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Component/s | OData URL Conventions [ 10270 ] | |
| Component/s | OData CSDL [ 10268 ] |
| Assignee | Ralf Handl [ ralfhandl ] |
| Resolution | https://www.oasis-open.org/committees/download.php/48379/odata-core-v4.0-wd01-part2-url-conventions-2013-02-25-RH.doc | |
| Status | Resolved [ 5 ] | Applied [ 10002 ] |
| Assignee | Ralf Handl [ ralfhandl ] | Ralf Handl [ handl ] |
| Reporter | Evan Ireland [ evan.ireland ] | Evan Ireland [ evan.ireland.2 ] |
Consider also that the protocol spec (2013-03-12) states:
10.4.1.3 Handling of DateTimeOffset Values
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.
Again this suggests that year, month, day, hour, minute, second, and totaloffsetminutes filter functions are meaningless unless the value is converted to UTC implicitly during their application. It is no use to clients if the value used in filter evaluation depends on whether or not the server can preserve the zone offsets for stored values.