[OASIS Issue Tracker] Commented: (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=31234#action_31234 ] 

Evan Ireland commented on ODATA-124:
------------------------------------

I don't think that *encouraging* the use of canonical lexical representation (for any types) would address my concern.
Neither would *requiring* the use of canonical lexical representation, as that would affect (narrow) only the "lexical space" for those types.

My concern is about the value semantics, which affects the "value space", not the "lexical space".

I am of course assuming that it is reasonable and appropriate for us to borrow the concepts of "value space" and "lexical space" from XML Schema, so that we can more formally define the semantics of OData values.

Rather than us placing specific requirements on round-tripping, it may be best for us to just clearly define the "value space" for each type. For DateTime(Offset) specifically, I am suggesting that, in variance from XML Schema, we disallow leap seconds and also consider the zone offset to be significant in the "value space".


> 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