[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ODATA-112) DateTime[Offset]: allow 24:00[:00] in time part
[ http://tools.oasis-open.org/issues/browse/ODATA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31263#action_31263 ] Stefan Drees commented on ODATA-112: ------------------------------------ In effect, I share the position as illustrated in the comment by Mike. After all, a server MAY always accept both 00:00 and 24:00 as long as it maps both literals to the identical and correct (from our point of view) time in storage (which we are agnostic of). But also in RFC822 (the ABNF cited by Mike) time literals like 99:99:99 or 24:00:00 are allowed, aren't they? ... "; 00:00:00 - 23:59:59 " (only a comment!) is better not normative in an ABNF grammar Looking for the definition of 2DIGIT in the RFC822 yields: 2.6. NRULE: SPECIFIC REPETITION "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, [...] End of citation. Coming back to tool support: On the one hand I know, that in eg. MySQL "24:00" as time literal is a no-no (eg. due to "Invalid TIME values, which are converted to '00:00:00' ... " or blocking when in strict mode). So I share Mike's expectation, that this proposed change WILL introduce many possibly subtle unexpected value changing or (when operating in "STRICT"-modes) service blocking errors. On the other hand, I do not know, if it really is a MUST NOT (from our side). For instance, when looking at some real world SQL parsing eg. A) PostgreSQL 8.5. Date/Time Types at http://www.postgresql.org/docs/9.2/static/datatype-datetime.html it states: PostgreSQL supports the full set of SQL date and time types, shown in Table 8-9. ... Name Storage Size Description Low Value High Value Resolution time [ (p) ] [ without time zone ] 8 bytes time of day (no date) 00:00:00 24:00:00 1 microsecond / 14 digits time [ (p) ] with time zone 12 bytes times of day only, with time zone 00:00:00+1459 24:00:00-1459 1 microsecond / 14 digits End of citation. or somewhere deep inside B) "SQL Server Integration Services " http://msdn.microsoft.com/en-us/library/ms141005.aspx one finds: ... Fast parse supports the following string formats for time data: * Time formats that include leading white spaces. For example, the value " 10:24" is valid. * 24-hour format. Fast parse does not support the AM and PM notation. * ISO 8601 time formats, as listed in the following table: ... All of the example values: "00:00:00", "000000", "0000", "00", "240000", "24:00:00", "2400", "24" to be interpreted as "The format for midnight." ... * Time values that include a leap second, as shown in the following examples: "23:59:60[.0000000]", "2235960[.0000000]" Fast parse outputs the strings as DT_DBTIME and DT_DBTIME2. Time values in truncated formats are padded. For example, HH:MI becomes HH:MM:00.000. ... End of citation. > DateTime[Offset]: allow 24:00[:00] in time part > ----------------------------------------------- > > Key: ODATA-112 > URL: http://tools.oasis-open.org/issues/browse/ODATA-112 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Bug > Components: OData CSDL v1.0 > Affects Versions: WD01 > Environment: [Proposed] > Reporter: Ralf Handl > Assignee: Ralf Handl > Priority: Minor > Fix For: WD01 > > > http://www.w3.org/TR/xmlschema-2/#dateTime allows 24 in the hour part of a dateTime if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day. -- 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]