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

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

Evan Ireland commented on ODATA-122:

Consider also that the protocol spec (2013-03-12) states: 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.

> Please clarify the meaning of filter functions applied to DateTimeOffset values
> -------------------------------------------------------------------------------
>                 Key: ODATA-122
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-122
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Task
>          Components: OData URL Conventions 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>            Assignee: Ralf Handl
>             Fix For: V4.0_WD01
> 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]