[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (ODATA-11) date/time values without explicit time zones need further investigation
[ http://tools.oasis-open.org/issues/browse/ODATA-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31115#action_31115 ]
Evan Ireland edited comment on ODATA-11 at 9/6/12 12:08 AM:
------------------------------------------------------------
We grappled with some particularly difficult issues in this area with Sybase Unwired Platform.
Folks may want to review how we dealt with this:
http://dcx.sybase.com/sup0212/en/com.sybase.infocenter.dc01781.0212/doc/html/fre1255554151996.html
My advice, based on our experiences, is this:
(1) OData DateTime should be defined as zone-indepdendent, and should NEVER include a zone offset. Like the "LocalDateTime" data type in JSR 310, or System.DateTime with DateTimeKind.Unspecified for .NET.
(2) OData DateTimeOffset should be defined always to include a zone offset from UTC (or "Z" for zero offset, as with XML Schema Part 2: Datatypes). Like the "OffsetDateTime" data type in JSR 310, or System.DateTime with DateTimeKind.UTC for .NET.
Some folks may think that DateTime should instead be a type with an optional zone offset. This kind of "ambiguous" type (I like to call it DateTimeWithOptionalOffset) is a disaster for interoperability.
If there was one thing I would do with XML Schema Part 2: Datatypes, is to define specific subtypes of date/time/dateTime that are zone-independent (no zone offset), and specific subtypes that have zone offset. As its stands, people have resorted to using restriction using "pattern" to achieve what they need, but such complex type definitions should not be needed to cover basic business concepts.
Here are the distinct types I think are essential:
Date (without zone offset)
Time (without zone offset)
DateTimeOffset (with zone offset)
I might (but probably not) be able to be convinced that DateTime (without zone offset) should be omitted, although that puts a burden on systems that want to expose data that is already zone-independent. You can't necessarily just slap an offset onto an existing zoneless value and represent it as zoned. That can result in round-trip errors when data is sent from EIS to client and back again.
I would absolutely advise to eliminate DateTimeWithOptionalOffset (which as I read the current spec draft correctly, we are calling DateTime).
was (Author: evan.ireland):
We grappled with some particularly difficult issues in this area with Sybase Unwired Platform.
Folks may want to review how we dealt with this:
http://dcx.sybase.com/sup0212/en/com.sybase.infocenter.dc01781.0212/doc/html/fre1255554151996.html
My advise, based on our experiences, is this:
(1) OData DateTime should be defined as zone-indepdendent, and should NEVER include a zone offset. Like the "LocalDateTime" data type in JSR 310, or System.DateTime with DateTimeKind.Unspecified for .NET.
(2) OData DateTimeOffset should be defined always to include a zone offset from UTC (or "Z" for zero offset, as with XML Schema Part 2: Datatypes). Like the "OffsetDateTime" data type in JSR 310, or System.DateTime with DateTimeKind.UTC for .NET.
Some folks may think that DateTime should instead be a type with an optional zone offset. This kind of "ambiguous" type (I like to call it DateTimeWithOptionalOffset) is a disaster for interoperability.
If there was one thing I would do with XML Schema Part 2: Datatypes, is to define specific subtypes of date/time/dateTime that are zone-independent (no zone offset), and specific subtypes that have zone offset. As its stands, people have resorted to using restriction using "pattern" to achieve what they need, but such complex type definitions should not be needed to cover basic business concepts.
Here are the distinct types I think are essential:
Date (without zone offset)
Time (without zone offset)
DateTimeOffset (with zone offset)
I might (but probably not) be able to be convinced that DateTime (without zone offset) should be omitted, although that puts a burden on systems that want to expose data that is already zone-independent. You can't necessarily just slap an offset onto an existing zoneless value and represent it as zoned. That can result in round-trip errors when data is sent from EIS to client and back again.
I would absolutely advise to eliminate DateTimeWithOptionalOffset (which as I read the current spec draft correctly, we are calling DateTime).
> date/time values without explicit time zones need further investigation
> -----------------------------------------------------------------------
>
> Key: ODATA-11
> URL: http://tools.oasis-open.org/issues/browse/ODATA-11
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: OData CSDL v1.0
> Reporter: Andrew Eisenberg
> Assignee: Michael Pizzo
>
> The reflection in OData of date/time values without explicit time zones needs further investigation.
> One way in which this issue manifests itself is in the comparison of a datetime value with a timezone to a datetime value without a timezone.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]