OASIS Open Data Protocol (OData) TC
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-220

Please consider the restoration of DateTime (without offset)

    Details

    • Type: Improvement Improvement
    • Status: Deferred
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V4.0_CSD01
    • Fix Version/s: V5.0_WD01
    • Component/s: CSDL XML
    • Labels:
      None
    • Environment:
      [Proposed]

      Description

      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.

        Activity

        Hide
        Evan Ireland (Inactive) added a comment -
        And a reminder, that a zoneless dateTime paired with a region code (e.g. TZID, MSFT or IANA) is usually going to be more appropriate for future events than a dateTime with offset.
        Show
        Evan Ireland (Inactive) added a comment - And a reminder, that a zoneless dateTime paired with a region code (e.g. TZID, MSFT or IANA) is usually going to be more appropriate for future events than a dateTime with offset.
        Hide
        Ralf Handl (Inactive) added a comment -
        Which time zone id or region code standard(s) should we select?
        Show
        Ralf Handl (Inactive) added a comment - Which time zone id or region code standard(s) should we select?
        Hide
        Evan Ireland (Inactive) added a comment -
        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.
        Show
        Evan Ireland (Inactive) added a comment - 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.
        Hide
        Ralf Handl (Inactive) added a comment -
        Evan and I agreed to defer this to a future version
        Show
        Ralf Handl (Inactive) added a comment - Evan and I agreed to defer this to a future version

          People

          • Assignee:
            Unassigned
            Reporter:
            Evan Ireland
          • Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: