[pubcomment-l] some comments on CC/FDS 18011:2018

[Michael H Deckers]

    The following are a few comments about [CalConnect 2019].

    Reference:
        [CalConnect 2019] The Calendaring and Scheduling Consortium:
        "CC/FDS 18011:2018  Date and time -- Explicit
        representation".  as of 2019-06-15.
        online at
        [https://standards.calconnect.org/csd/cc-18011.pdf]

    [section 3.2.4, p 11]

       The word, "positive" means > 0, but the tokens
       'i' and 'n' take the value zero in some cases.
       Hence, "positive" must be replaced by "non-negative"
       or by ">= 0".


     [section 4.4.7. Calendar year before year one, EXAMPLE 4, p 22]

         The example is incorrect:
             " ‘12CB’ the twelfth century before year one,
                      equivalent to the effect of time interval
                      ‘-1190/-1100’.  "
         because the given interval contains only 91 years.

         So, the example should be reworded as:
               ‘12CB’ the twelfth century before year one,
                      effectively equivalent to the time intervals
                      ‘-1199Y/-1100Y’ and '1200YB/1101YB'.

         But that is only one of the problems with this
         section. There are two other problems.

         The first is that ISO 8601-2:2019 does not allow
         notations like ‘12CB’ but instead uses '-11C' for
         this same century (which is not allowed by CalConnect).

         I think that the choice of ISO is very bad because
         of the error prone (and tasteless) distinction
         between '-0C' and '0C'; but CalConnect should at
         least mention the discrepancy.

         The other problem is that this definition of
         century does not agree with the definition in
         ISO 8601, which is included into [section 3] by
         reference. (Yes, this is also an error in
         ISO 8601.)

     [section 8.4 . Composite duration, step b]

         Step b is a kind of normalization of a datetime
         expressed with calendar date and time components
         that may assume values outside their customary ranges.
         It is described as:
              "In the resulting date and time representation,
               start from the lowest order overflowed time scale
               component, perform carry-over on all overflowed
               time scale components, until there is no more
               overflow in the representation. "

         This recipe fails to say how an overflow in a day of
         the month component is to be detected when the higher
         order component also overflows. As an example, consider
         the addition
             '2015Y02M28 + P12M2D'
         which results in the notation '2015Y14M30D' with
         some components out of their customary range.

         In order to see whether the component '30D' is in
         range or not, one would have to reduce the overflow
         in the month field, '2015Y14M' to '2016Y02M', so that
         we would finally obtain '2016Y03M01D' -- but this would
         be against the recipe which requires dealing first with
         any overflow in the '30D' component before we consider
         the overflow in the month component.
         So do we have to use the original value '2015Y02M'
         for the reduction of '30D'? This would yield
         '2015Y15M02D' and '2016Y03M02D' on further reductions.
         Or do we just have to leave the '30D' component as is
         (because it just may not overflow) and then reduce to
         '2016Y02M30D' which will be truncated in step c to
         '2016Y02M29D'?

         The recipe leaves us with 3 possible outcomes, and
         a more precise specification is needed when a reliable
         arithmetic is desired. (A similar question arises
         with arithmetic on ITU-R leap second notaions but
         that is thoroughly obscure anyway.)

    Michael Deckers.