[OASIS Issue Tracker] Updated: (ODATA-220) Please consider the restoration of DateTime (without offset)

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

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

Ralf Handl updated ODATA-220:
-----------------------------

    Proposal: 
Defer to 5.0

Accepted: https://www.oasis-open.org/committees/download.php/49375/odata-meeting-39_on-20130530-minutes.html#odata-220

  was:Defer to 5.0


> Please consider the restoration of DateTime (without offset)
> ------------------------------------------------------------
>
>                 Key: ODATA-220
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-220
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData CSDL
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>             Fix For: V5.0_WD01
>
>
> In odata_1396.ezm (odata digest message), I noted:
> Accepted: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/47764/latest/odata-meeting-19_on-20121220-minutes.html
>   was:
> -Remove Edm.DateTime (with no offset).
> ...
> I am sorry that I was unable to join conference calls to discuss this before it was voted on, but the calls are a little early in the day for me to attend.
> In various other discussions in the ODATA issues list, I think that we established that sometimes it may makes more sense for an object to have a separate field containing time zone name or offset, e.g. see xCal specification section 4.3.5 (http://tools.ietf.org/html/rfc5545#section-3.3.5) has DATE-TIME without offset, and a separate field type of UTC OFFSET for the offset (in OData this could easily be stored as a "short" number of minutes, I am not going to propose a separate OData type for UTC offset).
> I cannot see a strong rationale for eliminating DateTime (without offset) while adding Date (without offset) and TimeOfDay (without offset). To be clear, I do not mean to suggest eliminating zoneless Date and TimeOfDay.
> It seems reasonable to expect to be able to encapsulate xCal data in OData, without having to map multiple xCal fields (e.g. of types DATE-TIME and UTC OFFSET) into a single OData type (e.g. of type DateTimeOffset).
> Also, bear in mind the enormous number of systems where backend data (with DateTime fields having no offset) may be exposed via OData, not because they are to be "published to the web for the whole world to see and therefore should be zoned", but just because OData is the "flavour of the day" for integrating backends with newly developed front-end applications. Forcing developers to reinterpret zoneless DateTime data as zoned, as opposed to leaving it unzoned with explicit (or implicit) separate fields indicating zone name or offset, seems rather extreme. We can encourage developers to use DateTimeOffset where appropriate, but without being heavy-handed and eliminating zoneless DateTime.

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