[OASIS Issue Tracker] Commented: (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:comment-tabpanel&focusedCommentId=32707#action_32707 ] 

Evan Ireland commented on ODATA-220:
------------------------------------

Concrete proposal
=================

Add data type "LocalDateTime" (note name alignment with JSR 310 / JDK 1.8 time API, and that accordingly for consistency we might elect to rename "Date" as "LocalDate" and "TimeOfDay" as "LocalTime"). The principal purpose of this type is to allow the publishing of data which has a known origin zone, but for which the exact "instant in time" (in relation to UTC) may be unrecorded or meaningless (for future events) in the system of record, resulting in the possibility of round-tripping errors if the values were forced to be misrepresented as a definite instant in time using DateTimeOffset. The proposed lexical representation is as for XML schema dateTime without zone offset. 

When LocalDateTime is used in CSDL for a Property or Parameter, there should be an associated facet "TZID". The value of "TZID" must match a "Zone" region name from the IANA time zone database. See "Time Zone Data" link at:

    http://www.iana.org/time-zones

The default value for the "TZID" facet could be "Etc/UTC".

Or, we could require the facet to be specified in this release if we decide against supporting variable timezone, and allow a special value "variable" at such time that we decide to support variable timezeone. Note the similarity with the CSDL handling of SRID for geo types (i.e. the use "variable" in SRID facet).

Variable timezone
=================

LocalDateTime may be particularly useful for recording the intended time of future events, which are not at a guaranteed precise UTC instant because of the possibility of DST rules changing between the creation of an event record and the actual occurrence of the event (i.e. the events may "float" to the correct civil time at the designated main event location). However in this case it is useful to allow the TZID to be included in the values rather than being a constant facet. Borrowing from JSR 310 ZonedDateTime (which does have an offset, but please ignore that for the moment), the lexical representation of such values could be like this:

    2013-03-12T10:30[Pacific/Auckland]

(no zone offset, just region name)

If the region id is omitted it could be interpreted as being "Etc/UTC", as is the convention with JDK 1.8 ZonedDateTime.


> 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
>            Reporter: Evan Ireland
>
> 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