-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: V4.01_CS01
-
Fix Version/s: V4.01_CS02
-
Component/s: URL Conventions, Vocabularies
-
Labels:None
-
Environment:
Applied
-
Proposal:
-
Resolution:
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.