Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-1229

Introduce LocalDateTime TypeDef to apply to string datatype

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.01_CS01
    • Fix Version/s: V4.01_CS02
    • Labels:
      None
    • Environment:

      Applied

    • Proposal:
      Hide

      1) Introduce a new Core type annotation:

      <TypeDefinition Name="LocalDateTime" UnderlyingType="Edm.String">
        <Annotation Term="Description" String="A string representing a Local DateTime value with no offset."/>
         <Annotation Term="Validation.Pattern" String="^[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):[0-5][0-9](:[0-5][0-9](\\.[0-9]+)?)?$"/>
      </TypeDefinition>
      

      2) Define the cast function to Edm.DateTimeOffset to allow a string representation of a datetime value with no offset; the result is the specified value as UTC.

      Show
      1) Introduce a new Core type annotation: <TypeDefinition Name= "LocalDateTime" UnderlyingType= "Edm.String" > <Annotation Term= "Description" String= "A string representing a Local DateTime value with no offset." /> <Annotation Term= "Validation.Pattern" String= "^[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):[0-5][0-9](:[0-5][0-9](\\.[0-9]+)?)?$" /> </TypeDefinition> 2) Define the cast function to Edm.DateTimeOffset to allow a string representation of a datetime value with no offset; the result is the specified value as UTC.
    • Resolution:
      Show
      https://github.com/oasis-tcs/odata-vocabularies/pull/23 https://www.oasis-open.org/committees/download.php/64118/odata-v4.01-wd06-part2-url-conventions-2018-10-19.docx  

      Description

      One of our first actions as a Technical Committee was to remove the Edm.DateTime datatype in favor of Edm.DateTimeOffset. See ODATA-11.

      While there were good reasons for doing this, it has been a singularly unpopular decision, especially for services integrating with legacy systems that don't carry timezone information.

      It would be a breaking change to add a new datatype in 4.x, would add complexity by expanding the set of data types (especially when all date/time values are serialized as string in JSON) and would encourage a particular anti-pattern (DateTime values without timezone).

      Still, we should listen to the continual feedback (for example, see https://github.com/OData/WebApi/issues/136) and provide a means of representing such values.

      Today, the fallback is to represent such values as strings, but the semantics of what the string represents, including use within a URL and client representation in a strongly typed language, are lost.

      A reasonable compromise would be to add a core vocabulary term that could be used to annotate a string as representing a "LocalTime" value. The format of the string would have to comply with the Date and Time portions of the existing Edm.DateTimeOffset data type. We could require services that use this annotation to support implicit conversions of such properties (and correctly formatted string literals?) to DateTimeOffset with UTC.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: