[OASIS Issue Tracker] Issue Comment Edited: (ODATA-124) For round-tripping values, what precision must agents support for DateTime(Offset), and are leap seconds permitted?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31186#action_31186 ] 

Evan Ireland edited comment on ODATA-124 at 9/17/12 7:07 PM:
-------------------------------------------------------------

Ralf requested some clarity for my question, so here goes.

Consider this a sub-task for ODATA-52. Considering the "value space" (not "lexical space") of DateTime(Offset) types:

(1) Are leap seconds supported? OData V3 lexical representation suggests the answer is "yes", but the odata-abnf-construction-rules-v1.0-wd01.htm suggests the answer is "no", as the value "60" for second is not permitted. I would suggest that OData V4 should explicitly NOT support leap seconds, as does HTML5.

(2) Should there be a maximum value for the Precision facet? OData V3 CSDL doesn't specify a maximum Precision for DateTime(Offset) types, but OData V3 dateTimeLiteral is limited to Precision of 7 (100 nanoseconds).
I would suggest that 6 should be the maximum Precision that agents are required to support (based on the false accuracy issue particularly when considering "leap smear" and the related ways in which leap seconds are handled).

(3) Should there be a default value for the Precision facet? I would suggest that the answer should be yes, default Precision = 3, since most clocks are not synchronized to more than millisecond accuracy, so a Precision of more than 3 for DateTime(Offset) is in most cases going to result in false accuracy.

So those are the questions to be answered. For the rationale, since many agents will be unable to support arbitrary Precision for DateTime(Offset) (or > 3 for some systems, or > 6 for some others), it is important that we specify maximum and default Precision so that agents, based on meta-data of a service, determine if they are able (or not) to support all the values that might be seen in request/response payloads, and therefore meet the contract of a service as defined by the CSDL.

Consider the following maximum precisions, and the fact that OData is often going to be used with these technologies:

(a) Java: java.util.Date (millisecond precision), java.sql.Time (millisecond precision), java.sql.Timestamp (nanosecond precision)

(b) .NET: System.DateTime(Offset): 100 nanosecond precision

(b) Oracle databases: nanosecond precision (maximum)

(c) Sybase databases: microsecond precision (maximum)


      was (Author: evan.ireland):
    Ralf requested some clarity for my question, so here goes.

Consider this a sub-task for ODDATA-52. Considering the "value space" (not "lexical space") of DateTime(Offset) types:

(1) Are leap seconds supported? OData V3 lexical representation suggests the answer is "yes", but the odata-abnf-construction-rules-v1.0-wd01.htm suggests the answer is "no", as the value "60" for second is not permitted. I would suggest that OData V4 should explicitly NOT support leap seconds, as does HTML5.

(2) Should there be a maximum value for the Precision facet? OData V3 CSDL doesn't specify a maximum Precision for DateTime(Offset) types, but OData V3 dateTimeLiteral is limited to Precision of 7 (100 nanoseconds).
I would suggest that 6 should be the maximum Precision that agents are required to support (based on the false accuracy issue particularly when considering "leap smear" and the related ways in which leap seconds are handled).

(3) Should there be a default value for the Precision facet? I would suggest that the answer should be yes, default Precision = 3, since most clocks are not synchronized to more than millisecond accuracy, so a Precision of more than 3 for DateTime(Offset) is in most cases going to result in false accuracy.

So those are the questions to be answered. For the rationale, since many agents will be unable to support arbitrary Precision for DateTime(Offset) (or > 3 for some systems, or > 6 for some others), it is important that we specify maximum and default Precision so that agents, based on meta-data of a service, determine if they are able (or not) to support all the values that might be seen in request/response payloads, and therefore meet the contract of a service as defined by the CSDL.

Consider the following maximum precisions, and the fact that OData is often going to be used with these technologies:

(a) Java: java.util.Date (millisecond precision), java.sql.Time (millisecond precision), java.sql.Timestamp (nanosecond precision)

(b) .NET: System.DateTime(Offset): 100 nanosecond precision

(b) Oracle databases: nanosecond precision (maximum)

(c) Sybase databases: microsecond precision (maximum)

  
> For round-tripping values, what precision must agents support for DateTime(Offset), and are leap seconds permitted?
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-124
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-124
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Task
>          Components: OData CSDL v1.0
>    Affects Versions: WD01
>            Reporter: Evan Ireland
>            Priority: Minor
>             Fix For: WD01
>
>
> We should define a minimum precision that agents must support for DateTime(Offset) when progapating values or proxying requests, and be explicit about whether leap seconds can/must be supported.
> Assuming for a moment that OData DateTime(Offset) does not support leap seconds, then suppose a computer system that implements "leap smear" over a day, by 1,000,000 microseconds smeared evenly over a day. That is approximately 12 (11.57) microseconds per second. The point here is that allowing for microsecond precision in DateTime(Offset) values in this case would amount to a "false" precision (the value may be less "accurate" than it is "precise"), given the variable length of seconds from day to day (the day before the leap second is observed, and the day the leap second is observed).
> Now while I appreciate that the lexical representation of date/times in OData V3 allows seconds=60 and that therefore presumably the intention was to support leap seconds, OData is likely to be used frequently together with HTML5 (which does not permit leap seconds or sub-millisecond precision), so I would recommend that OData should align with HTML5 and disallow leap seconds and sub-millisecond precision.
> See also: http://blogs.msdn.com/b/ericlippert/archive/2010/04/08/precision-and-accuracy-of-datetime.aspx

-- 
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