new features of ISO 8601:2019

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

new features of ISO 8601:2019

Michael H Deckers
    The following __LOOONG__  post is a list of things new in
    ISO 8601 of 2019-02-28 with respect to the previous edition
    ISO 8601:2004.

    ∙  ISO 8601 now has two parts:
       The first part, ISO 8601-1:2019 describes the notations
       of the previous standard, ISO 8601:2004, with only minor
       changes:
       ∘  the alternative time notation for midnight at the end
          of the day, time of day 24:00:00 has been abolished
       ∘  three digit numbers are taken as notation for "decades"

    ∙  there are also changes in the terminology
       ∘  "duration" is used for what physicists call time while
          "time" is used for date with or without time of day
          (ie, what astronomers call epoch and programmers call
          datetime)
       ∘  "time scale components" are the fields for year number,
          month number,..seconds of the minute number of a
          date or time
       ∘  "time scale unit" are the (formal) time "units" for
          these components
       ∘  "expression" is one of the notations for dates, durations,
          and date intervals, while "representation" is a notation
          for the format of an expression

    ∙  the description method is essentially unchanged
       ∘  there still is no formal specification of the
          allowed formats (although the 2017 draft contained one)
       ∘  there are lots of errors in the text, not only typos
          but also wrong examples and inconsistent statements
          where the intention of the authors is not clear
       ∘  and, yes, the old errors persist:
          the notations 2017-03-08T07 and 2017-03-08/2017-04 are
          (inadvertently) forbidden because they combine extended
          format (2017-03-08) with basic format (T07 and 2017-04);
          but 20170307/2017-04 is (inadvertently) allowed as it
          is completely in basic format

     ∙  most of the new stuff is in the second part, ISO 8601-2,
        and it is taken from two sources:
        ∘  the Library of Congress EDTF notation for dates
           with uncertainties;
        ∘  the notations of CalConnect that are intended to
           replace the (even more complex) RRULE notations
           of RFC 5545, used for the exchange of scheduling
           information
        Both sources are freely available while the new edition
        of ISO 8601 currently is not.

     ∙  there is a new "explicit format" notation for dates and
        times, taken from CalConnect, where each "time scale
        component" has a letter suffix (as the notations for
        duration always had):
        ∘  explicit formats 2019Y3M14D = 2019Y11W4K = 2019Y63O
           are the same as  2019-03-14 = 2019-W11-4 = 2019-063
           in "implicit format" (called implied" in ISO 8601-1).
        Several new formats for date notations are only available
        in the new "explicit format" but some of them would have
        been useful in the "implicit format" (as exemplified below):
        ∘  dates without time but with indication of time shift to UTC:
              2019Y3M14DZ1H     (2019-03-14+01:00 is still disallowed)
        ∘  subminute resolution in the time shift local vs UTC:
              1893Y4M1DZ46M12S  (1893-04-01+00:46:12 is disallowed)
        ∘  this allows for the notation of TAI values, such as
              2017Y1M1DT36SZ36S = 2017-01-01T00:00:36+00:00:36
           and
              2017Y1M1DT37SZ37S = 2017-01-01T00:00:37+00:00:37
           for the start and the end of the latest leap second
           2016-12-31T23:59:60Z.
        ∘  "time scale components" with value 0 can be omitted,
           so that 1M1DT0S is equivalent to 0000-01-01T00:00:00
        ∘  BCE year numbers can be used: 753YB4M13D = -0752-04-13
        ∘  negative week, day of the month and day of the year
           numbers are allowed; they count back from the last day
           or week of the year or month, starting with -1:
               2019Y2M-1D = 2019Y-44W4K = 2019-02-28 = 2019-W44-4
           (the astronomical numbering uses 2019-03-00 for
           2019-02-28 and is more systematic)
        ∘  but fractional day numbers as commonly used in
           astronomy are still not allowed

    ∙  the "explicit format" allows for quite complex notations:
       ∘  2019Y2G3MU50D specifies day 50 of the second quarter
          of 2019 (= 2019-05-20); instead of the "unit" month,
          it uses a "grouped unit" G3MU enclosed within G and U,
          formed by 3 (consecutive) months. Thus, instead of
          months, one may use cowznofskis (G100DU) or groups
          G1M10DU of one month plus 10 days
       ∘  2019Y3ML{25..31}D7KN specifies the last Sunday in March
          2019, where the "selection" substring L{25..31}D7KN
          enclosed between L and N selects from March 2019 (2019Y3M)
          the dates with day of the month numbers in the set {25..31},
          from which it then selects the Sundays (7K) (of which
          there is precisely one). Switches between summer and
          winter time often occur at such types of dates
       ∘  the scheme is not too well-designed because the first
          Sunday of Advent requires a more complex notation:
          2019Y11MLL27D/P6DN7KN uses a nested "inner selection"
          L27D/P6DN that first selects the interval of dates
          between November 27 and December 03, by specifying
          its start date and its length
       ∘  there are additional features in the "explicit format"
          for the definition of recurring time intervals of the
          same length that are not necessarily adjacent (which
          they are in ISO 8601-1). The scheme is similar to, but
          different from the RRULEs of iCalendar, and its
          description is less comprehensive. Some differences
          are described in a (non-normative) annex
       The "explicit format" notation is hard to decipher for
       human readers because of the mixing of (upper case) letters
       O, D, I, J, S, B with digits (as the sans-serif typeface of
       the standard amply demonstrates). But even computer parsing
       of the notation is non-trivial due to the nesting of the
       bracket structures G..U and L..N.

    ∙  the interpretation of some complex "explicit formats"
       requires date arithmetic, and the arithmetic of CalConnect
       is therefore described in a (non-normative) annex
       ∘  the addition of a date and a (formal) time is monotone
          in the (left) date argument:
             2019-01-28 +  1 month        = 2019-02-28
             2019-01-31 +  1 month        = 2019-02-28
             2019-02-01 +  1 month        = 2019-03-01
          but it is not monotone in the (right) time argument:
             2019-01-31 + (1 month - 1 d) = 2019-03-02
             2019-01-31 +  1 month        = 2019-02-28
             2019-01-31 + (1 month + 1 d) = 2019-03-04
       ∘  durations with mixed signs are allowed, such as
          P1M-30D for the difference 2019-02-01 less 2019-01-31,
          and 2019-01-31 + P1M-30D gives 2019-02-01 as expected
       ∘  "fractional" durations such as P1.5M are allowed,
          where 2019-01-30 + P1.5M is the midpoint 2019-03-15
          between 2019-01-30 + 1 month and 2019-01-30 + 2 month
       ∘  the handling of leap seconds in CalConnect is faulty
          because it allows for leap seconds only at midnight
          at the end of a year, even in local time scales,
          while the leap second 2015-07-01T08:59:60+09 happened
          in the middle of the year during business hours
          in Tokyo

    ∙  several different ways have been introduced (following
       EDTF) to indicate uncertainty in a date or time of day
       ∘  numerical values in a date or in a time of day
          in extended format can be prefixed with:
            ~  to indicate an "approximate" value;
            ?  to indicate an "uncertain" (unreliable) value
            %  to indicate both "approximate" and "uncertain" values
          Thus, in 2019-?03-~04, March is "uncertain" and 04 is
          "approximate"
       ∘  the markers ~ ? % can also follow the numerical value, in
          which case they apply to all numerical values to its left:
              ~2019-03?-~04  and  %2019-?03-~04
          both indicate that 2019 is "approximate" and "uncertain",
          03 is "uncertain" and 04 is "approximate" -- there are
          many cases where multiple notations are possible
       ∘  a digit in a date or time of day in extended format
          can be replaced by the letter X to indicate that it is
          "unspecified": 2019-1X-XX is an otherwise unspecified
          day in the last quarter of 2019.
          Indicating illegible digits in a date would probably be
          most frequent for dates before 1752 -- but the notation
          applies to unspecified digits of Gregorian dates
       ∘  in addition to dates with reduced precision (as eg, 2019-03),
          subdivisions of a year with lower resolution than month
          use a number from 21 to 41 in place of the month number:
             2019-21  spring of 2019
             2019-22  summer of 2019
             2019-26  northern summer of 2019
             2019-30  southern summer of 2019
             2019-34  second quarter of 2019
             2019-38  second "quadrimester" (4-month period)
             2019-41  second semester of 2019
       ∘  the preceding marks can also be used in "explicit format":
          2019Y3?M4D, 2019~Y3M?4~D, 2019%Y3?M4~D, 2019Y1XMX*D,
          2019Y21A, 2019Y22A, etc
       ∘  a date with only a year number (in the far past or far
          future) can be written in floating point notation and,or
          with an indication of the number of (leading) significant
          digits: thus Y-2990E5S3 means the Gregorian year -299.0₁₀6
          with 3 significant digits (beginning of the Permian period).
          For scientific purposes, this notation is unsuitable:
          indicating the (one sigma) uncertainty of the value would
          require a fractional number of significant (decimal) digits.
          Geologists write the date as (299.0 ± 0.8) Ma BP (before
          present), where the uncertainty is clearly indicated.
       The large variety of formats for approximate dates corresponds
       to the multitude of indicated aspects ("approximate",
       "uncertain", "unspecified", "significant", "hemispherical
       season") whose meanings and differences unfortunately remain
       unexplained.

    ∙  The standard specifies how users can agree on subsets of
       the features of ISO 8601 so that a reader of ISO 8601 data
       need not be able to understand all the formats
       ∘  a "profile" can be defined that lists features of ISO 8601,
          and "levels" within the profile can indicate subsets of
          the list, indicating the features that may be used in
          a communication
       ∘  an example profile, with the EDTF levels 0, 1, 2 is given
       ∘  the "mutual agreement" between communication partners
          (as posited in ISO 8601-1 for several features) is not
          addressed in a standardized profile. It requires
          parameterized features (eg, the number of additional
          digits in a year number) which are not provided in the
          proposed profiles

    ∙  ISO charges 336 CHF (about 336 US$) for the two parts with
       134 pages, that's about 7 bottles of a decent champagne.
       Think before you buy.

    Michael Deckers.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Walter J Ziobro

Dear Michael et al

I thank you for the very thorough summary of changes in ISO 1860

Do the seasonal subdivisions have specific start dates, or are the astronomical equinoxes and Solstices assumed?

Walter Ziobro




On Saturday, April 6, 2019 Michael H Deckers <[hidden email]> wrote:

   The following __LOOONG__  post is a list of things new in
   ISO 8601 of 2019-02-28 with respect to the previous edition
   ISO 8601:2004.

   ∙  ISO 8601 now has two parts:
      The first part, ISO 8601-1:2019 describes the notations
      of the previous standard, ISO 8601:2004, with only minor
      changes:
      ∘  the alternative time notation for midnight at the end
         of the day, time of day 24:00:00 has been abolished
      ∘  three digit numbers are taken as notation for "decades"

   ∙  there are also changes in the terminology
      ∘  "duration" is used for what physicists call time while
         "time" is used for date with or without time of day
         (ie, what astronomers call epoch and programmers call
         datetime)
      ∘  "time scale components" are the fields for year number,
         month number,..seconds of the minute number of a
         date or time
      ∘  "time scale unit" are the (formal) time "units" for
         these components
      ∘  "expression" is one of the notations for dates, durations,
         and date intervals, while "representation" is a notation
         for the format of an expression

   ∙  the description method is essentially unchanged
      ∘  there still is no formal specification of the
         allowed formats (although the 2017 draft contained one)
      ∘  there are lots of errors in the text, not only typos
         but also wrong examples and inconsistent statements
         where the intention of the authors is not clear
      ∘  and, yes, the old errors persist:
         the notations 2017-03-08T07 and 2017-03-08/2017-04 are
         (inadvertently) forbidden because they combine extended
         format (2017-03-08) with basic format (T07 and 2017-04);
         but 20170307/2017-04 is (inadvertently) allowed as it
         is completely in basic format

    ∙  most of the new stuff is in the second part, ISO 8601-2,
       and it is taken from two sources:
       ∘  the Library of Congress EDTF notation for dates
          with uncertainties;
       ∘  the notations of CalConnect that are intended to
          replace the (even more complex) RRULE notations
          of RFC 5545, used for the exchange of scheduling
          information
       Both sources are freely available while the new edition
       of ISO 8601 currently is not.

    ∙  there is a new "explicit format" notation for dates and
       times, taken from CalConnect, where each "time scale
       component" has a letter suffix (as the notations for
       duration always had):
       ∘  explicit formats 2019Y3M14D = 2019Y11W4K = 2019Y63O
          are the same as  2019-03-14 = 2019-W11-4 = 2019-063
          in "implicit format" (called implied" in ISO 8601-1).
       Several new formats for date notations are only available
       in the new "explicit format" but some of them would have
       been useful in the "implicit format" (as exemplified below):
       ∘  dates without time but with indication of time shift to UTC:
             2019Y3M14DZ1H     (2019-03-14+01:00 is still disallowed)
       ∘  subminute resolution in the time shift local vs UTC:
             1893Y4M1DZ46M12S  (1893-04-01+00:46:12 is disallowed)
       ∘  this allows for the notation of TAI values, such as
             2017Y1M1DT36SZ36S = 2017-01-01T00:00:36+00:00:36
          and
             2017Y1M1DT37SZ37S = 2017-01-01T00:00:37+00:00:37
          for the start and the end of the latest leap second
          2016-12-31T23:59:60Z.
       ∘  "time scale components" with value 0 can be omitted,
          so that 1M1DT0S is equivalent to 0000-01-01T00:00:00
       ∘  BCE year numbers can be used: 753YB4M13D = -0752-04-13
       ∘  negative week, day of the month and day of the year
          numbers are allowed; they count back from the last day
          or week of the year or month, starting with -1:
              2019Y2M-1D = 2019Y-44W4K = 2019-02-28 = 2019-W44-4
          (the astronomical numbering uses 2019-03-00 for
          2019-02-28 and is more systematic)
       ∘  but fractional day numbers as commonly used in
          astronomy are still not allowed

   ∙  the "explicit format" allows for quite complex notations:
      ∘  2019Y2G3MU50D specifies day 50 of the second quarter
         of 2019 (= 2019-05-20); instead of the "unit" month,
         it uses a "grouped unit" G3MU enclosed within G and U,
         formed by 3 (consecutive) months. Thus, instead of
         months, one may use cowznofskis (G100DU) or groups
         G1M10DU of one month plus 10 days
      ∘  2019Y3ML{25..31}D7KN specifies the last Sunday in March
         2019, where the "selection" substring L{25..31}D7KN
         enclosed between L and N selects from March 2019 (2019Y3M)
         the dates with day of the month numbers in the set {25..31},
         from which it then selects the Sundays (7K) (of which
         there is precisely one). Switches between summer and
         winter time often occur at such types of dates
      ∘  the scheme is not too well-designed because the first
         Sunday of Advent requires a more complex notation:
         2019Y11MLL27D/P6DN7KN uses a nested "inner selection"
         L27D/P6DN that first selects the interval of dates
         between November 27 and December 03, by specifying
         its start date and its length
      ∘  there are additional features in the "explicit format"
         for the definition of recurring time intervals of the
         same length that are not necessarily adjacent (which
         they are in ISO 8601-1). The scheme is similar to, but
         different from the RRULEs of iCalendar, and its
         description is less comprehensive. Some differences
         are described in a (non-normative) annex
      The "explicit format" notation is hard to decipher for
      human readers because of the mixing of (upper case) letters
      O, D, I, J, S, B with digits (as the sans-serif typeface of
      the standard amply demonstrates). But even computer parsing
      of the notation is non-trivial due to the nesting of the
      bracket structures G..U and L..N.

   ∙  the interpretation of some complex "explicit formats"
      requires date arithmetic, and the arithmetic of CalConnect
      is therefore described in a (non-normative) annex
      ∘  the addition of a date and a (formal) time is monotone
         in the (left) date argument:
            2019-01-28 +  1 month        = 2019-02-28
            2019-01-31 +  1 month        = 2019-02-28
            2019-02-01 +  1 month        = 2019-03-01
         but it is not monotone in the (right) time argument:
            2019-01-31 + (1 month - 1 d) = 2019-03-02
            2019-01-31 +  1 month        = 2019-02-28
            2019-01-31 + (1 month + 1 d) = 2019-03-04
      ∘  durations with mixed signs are allowed, such as
         P1M-30D for the difference 2019-02-01 less 2019-01-31,
         and 2019-01-31 + P1M-30D gives 2019-02-01 as expected
      ∘  "fractional" durations such as P1.5M are allowed,
         where 2019-01-30 + P1.5M is the midpoint 2019-03-15
         between 2019-01-30 + 1 month and 2019-01-30 + 2 month
      ∘  the handling of leap seconds in CalConnect is faulty
         because it allows for leap seconds only at midnight
         at the end of a year, even in local time scales,
         while the leap second 2015-07-01T08:59:60+09 happened
         in the middle of the year during business hours
         in Tokyo

   ∙  several different ways have been introduced (following
      EDTF) to indicate uncertainty in a date or time of day
      ∘  numerical values in a date or in a time of day
         in extended format can be prefixed with:
           ~  to indicate an "approximate" value;
           ?  to indicate an "uncertain" (unreliable) value
           %  to indicate both "approximate" and "uncertain" values
         Thus, in 2019-?03-~04, March is "uncertain" and 04 is
         "approximate"
      ∘  the markers ~ ? % can also follow the numerical value, in
         which case they apply to all numerical values to its left:
             ~2019-03?-~04  and  %2019-?03-~04
         both indicate that 2019 is "approximate" and "uncertain",
         03 is "uncertain" and 04 is "approximate" -- there are
         many cases where multiple notations are possible
      ∘  a digit in a date or time of day in extended format
         can be replaced by the letter X to indicate that it is
         "unspecified": 2019-1X-XX is an otherwise unspecified
         day in the last quarter of 2019.
         Indicating illegible digits in a date would probably be
         most frequent for dates before 1752 -- but the notation
         applies to unspecified digits of Gregorian dates
      ∘  in addition to dates with reduced precision (as eg, 2019-03),
         subdivisions of a year with lower resolution than month
         use a number from 21 to 41 in place of the month number:
            2019-21  spring of 2019
            2019-22  summer of 2019
            2019-26  northern summer of 2019
            2019-30  southern summer of 2019
            2019-34  second quarter of 2019
            2019-38  second "quadrimester" (4-month period)
            2019-41  second semester of 2019
      ∘  the preceding marks can also be used in "explicit format":
         2019Y3?M4D, 2019~Y3M?4~D, 2019%Y3?M4~D, 2019Y1XMX*D,
         2019Y21A, 2019Y22A, etc
      ∘  a date with only a year number (in the far past or far
         future) can be written in floating point notation and,or
         with an indication of the number of (leading) significant
         digits: thus Y-2990E5S3 means the Gregorian year -299.0₁₀6
         with 3 significant digits (beginning of the Permian period).
         For scientific purposes, this notation is unsuitable:
         indicating the (one sigma) uncertainty of the value would
         require a fractional number of significant (decimal) digits.
         Geologists write the date as (299.0 ± 0.8) Ma BP (before
         present), where the uncertainty is clearly indicated.
      The large variety of formats for approximate dates corresponds
      to the multitude of indicated aspects ("approximate",
      "uncertain", "unspecified", "significant", "hemispherical
      season") whose meanings and differences unfortunately remain
      unexplained.

   ∙  The standard specifies how users can agree on subsets of
      the features of ISO 8601 so that a reader of ISO 8601 data
      need not be able to understand all the formats
      ∘  a "profile" can be defined that lists features of ISO 8601,
         and "levels" within the profile can indicate subsets of
         the list, indicating the features that may be used in
         a communication
      ∘  an example profile, with the EDTF levels 0, 1, 2 is given
      ∘  the "mutual agreement" between communication partners
         (as posited in ISO 8601-1 for several features) is not
         addressed in a standardized profile. It requires
         parameterized features (eg, the number of additional
         digits in a year number) which are not provided in the
         proposed profiles

   ∙  ISO charges 336 CHF (about 336 US$) for the two parts with
      134 pages, that's about 7 bottles of a decent champagne.
      Think before you buy.

   Michael Deckers.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Michael H Deckers
    On 2019-04-06 14:22, Walter J Ziobro asked about ISO 8601:2019:


> Do the seasonal subdivisions have specific start dates, or are the astronomical equinoxes and Solstices assumed?



    Neither. ISO 8601:2019 does not specify what the "winter" or
    the "northern" or "southern winter" of the year 2019 is.
    It could be that 2019-01-01 and 2019-12-31 both belong
    to the "northern winter" of 2019, and that the "winter"
    (without hemisphere) may in addition comprise 2019-07-01.

    Michael Deckers.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

k.palmen@btinternet.com
In reply to this post by Walter J Ziobro
Dear Michael & Calendar People

Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?

Karl

Sunday Alpha April 2019
----Original message----
From : [hidden email]
Date : 06/04/2019 - 15:22 (BST)
To : [hidden email]
Subject : Re: new features of ISO 8601:2019

Dear Michael et al

I thank you for the very thorough summary of changes in ISO 1860

Do the seasonal subdivisions have specific start dates, or are the astronomical equinoxes and Solstices assumed?

Walter Ziobro




On Saturday, April 6, 2019 Michael H Deckers <[hidden email]> wrote:

   The following __LOOONG__  post is a list of things new in
   ISO 8601 of 2019-02-28 with respect to the previous edition
   ISO 8601:2004.

   ∙  ISO 8601 now has two parts:
      The first part, ISO 8601-1:2019 describes the notations
      of the previous standard, ISO 8601:2004, with only minor
      changes:
      ∘  the alternative time notation for midnight at the end
         of the day, time of day 24:00:00 has been abolished
      ∘  three digit numbers are taken as notation for "decades"

   ∙  there are also changes in the terminology
      ∘  "duration" is used for what physicists call time while
         "time" is used for date with or without time of day
         (ie, what astronomers call epoch and programmers call
         datetime)
      ∘  "time scale components" are the fields for year number,
         month number,..seconds of the minute number of a
         date or time
      ∘  "time scale unit" are the (formal) time "units" for
         these components
      ∘  "expression" is one of the notations for dates, durations,
         and date intervals, while "representation" is a notation
         for the format of an expression

   ∙  the description method is essentially unchanged
      ∘  there still is no formal specification of the
         allowed formats (although the 2017 draft contained one)
      ∘  there are lots of errors in the text, not only typos
         but also wrong examples and inconsistent statements
         where the intention of the authors is not clear
      ∘  and, yes, the old errors persist:
         the notations 2017-03-08T07 and 2017-03-08/2017-04 are
         (inadvertently) forbidden because they combine extended
         format (2017-03-08) with basic format (T07 and 2017-04);
         but 20170307/2017-04 is (inadvertently) allowed as it
         is completely in basic format

    ∙  most of the new stuff is in the second part, ISO 8601-2,
       and it is taken from two sources:
       ∘  the Library of Congress EDTF notation for dates
          with uncertainties;
       ∘  the notations of CalConnect that are intended to
          replace the (even more complex) RRULE notations
          of RFC 5545, used for the exchange of scheduling
          information
       Both sources are freely available while the new edition
       of ISO 8601 currently is not.

    ∙  there is a new "explicit format" notation for dates and
       times, taken from CalConnect, where each "time scale
       component" has a letter suffix (as the notations for
       duration always had):
       ∘  explicit formats 2019Y3M14D = 2019Y11W4K = 2019Y63O
          are the same as  2019-03-14 = 2019-W11-4 = 2019-063
          in "implicit format" (called implied" in ISO 8601-1).
       Several new formats for date notations are only available
       in the new "explicit format" but some of them would have
       been useful in the "implicit format" (as exemplified below):
       ∘  dates without time but with indication of time shift to UTC:
             2019Y3M14DZ1H     (2019-03-14+01:00 is still disallowed)
       ∘  subminute resolution in the time shift local vs UTC:
             1893Y4M1DZ46M12S  (1893-04-01+00:46:12 is disallowed)
       ∘  this allows for the notation of TAI values, such as
             2017Y1M1DT36SZ36S = 2017-01-01T00:00:36+00:00:36
          and
             2017Y1M1DT37SZ37S = 2017-01-01T00:00:37+00:00:37
          for the start and the end of the latest leap second
          2016-12-31T23:59:60Z.
       ∘  "time scale components" with value 0 can be omitted,
          so that 1M1DT0S is equivalent to 0000-01-01T00:00:00
       ∘  BCE year numbers can be used: 753YB4M13D = -0752-04-13
       ∘  negative week, day of the month and day of the year
          numbers are allowed; they count back from the last day
          or week of the year or month, starting with -1:
              2019Y2M-1D = 2019Y-44W4K = 2019-02-28 = 2019-W44-4
          (the astronomical numbering uses 2019-03-00 for
          2019-02-28 and is more systematic)
       ∘  but fractional day numbers as commonly used in
          astronomy are still not allowed

   ∙  the "explicit format" allows for quite complex notations:
      ∘  2019Y2G3MU50D specifies day 50 of the second quarter
         of 2019 (= 2019-05-20); instead of the "unit" month,
         it uses a "grouped unit" G3MU enclosed within G and U,
         formed by 3 (consecutive) months. Thus, instead of
         months, one may use cowznofskis (G100DU) or groups
         G1M10DU of one month plus 10 days
      ∘  2019Y3ML{25..31}D7KN specifies the last Sunday in March
         2019, where the "selection" substring L{25..31}D7KN
         enclosed between L and N selects from March 2019 (2019Y3M)
         the dates with day of the month numbers in the set {25..31},
         from which it then selects the Sundays (7K) (of which
         there is precisely one). Switches between summer and
         winter time often occur at such types of dates
      ∘  the scheme is not too well-designed because the first
         Sunday of Advent requires a more complex notation:
         2019Y11MLL27D/P6DN7KN uses a nested "inner selection"
         L27D/P6DN that first selects the interval of dates
         between November 27 and December 03, by specifying
         its start date and its length
      ∘  there are additional features in the "explicit format"
         for the definition of recurring time intervals of the
         same length that are not necessarily adjacent (which
         they are in ISO 8601-1). The scheme is similar to, but
         different from the RRULEs of iCalendar, and its
         description is less comprehensive. Some differences
         are described in a (non-normative) annex
      The "explicit format" notation is hard to decipher for
      human readers because of the mixing of (upper case) letters
      O, D, I, J, S, B with digits (as the sans-serif typeface of
      the standard amply demonstrates). But even computer parsing
      of the notation is non-trivial due to the nesting of the
      bracket structures G..U and L..N.

   ∙  the interpretation of some complex "explicit formats"
      requires date arithmetic, and the arithmetic of CalConnect
      is therefore described in a (non-normative) annex
      ∘  the addition of a date and a (formal) time is monotone
         in the (left) date argument:
            2019-01-28 +  1 month        = 2019-02-28
            2019-01-31 +  1 month        = 2019-02-28
            2019-02-01 +  1 month        = 2019-03-01
         but it is not monotone in the (right) time argument:
            2019-01-31 + (1 month - 1 d) = 2019-03-02
            2019-01-31 +  1 month        = 2019-02-28
            2019-01-31 + (1 month + 1 d) = 2019-03-04
      ∘  durations with mixed signs are allowed, such as
         P1M-30D for the difference 2019-02-01 less 2019-01-31,
         and 2019-01-31 + P1M-30D gives 2019-02-01 as expected
      ∘  "fractional" durations such as P1.5M are allowed,
         where 2019-01-30 + P1.5M is the midpoint 2019-03-15
         between 2019-01-30 + 1 month and 2019-01-30 + 2 month
      ∘  the handling of leap seconds in CalConnect is faulty
         because it allows for leap seconds only at midnight
         at the end of a year, even in local time scales,
         while the leap second 2015-07-01T08:59:60+09 happened
         in the middle of the year during business hours
         in Tokyo

   ∙  several different ways have been introduced (following
      EDTF) to indicate uncertainty in a date or time of day
      ∘  numerical values in a date or in a time of day
         in extended format can be prefixed with:
           ~  to indicate an "approximate" value;
           ?  to indicate an "uncertain" (unreliable) value
           %  to indicate both "approximate" and "uncertain" values
         Thus, in 2019-?03-~04, March is "uncertain" and 04 is
         "approximate"
      ∘  the markers ~ ? % can also follow the numerical value, in
         which case they apply to all numerical values to its left:
             ~2019-03?-~04  and  %2019-?03-~04
         both indicate that 2019 is "approximate" and "uncertain",
         03 is "uncertain" and 04 is "approximate" -- there are
         many cases where multiple notations are possible
      ∘  a digit in a date or time of day in extended format
         can be replaced by the letter X to indicate that it is
         "unspecified": 2019-1X-XX is an otherwise unspecified
         day in the last quarter of 2019.
         Indicating illegible digits in a date would probably be
         most frequent for dates before 1752 -- but the notation
         applies to unspecified digits of Gregorian dates
      ∘  in addition to dates with reduced precision (as eg, 2019-03),
         subdivisions of a year with lower resolution than month
         use a number from 21 to 41 in place of the month number:
            2019-21  spring of 2019
            2019-22  summer of 2019
            2019-26  northern summer of 2019
            2019-30  southern summer of 2019
            2019-34  second quarter of 2019
            2019-38  second "quadrimester" (4-month period)
            2019-41  second semester of 2019
      ∘  the preceding marks can also be used in "explicit format":
         2019Y3?M4D, 2019~Y3M?4~D, 2019%Y3?M4~D, 2019Y1XMX*D,
         2019Y21A, 2019Y22A, etc
      ∘  a date with only a year number (in the far past or far
         future) can be written in floating point notation and,or
         with an indication of the number of (leading) significant
         digits: thus Y-2990E5S3 means the Gregorian year -299.0₁₀6
         with 3 significant digits (beginning of the Permian period).
         For scientific purposes, this notation is unsuitable:
         indicating the (one sigma) uncertainty of the value would
         require a fractional number of significant (decimal) digits.
         Geologists write the date as (299.0 ± 0.8) Ma BP (before
         present), where the uncertainty is clearly indicated.
      The large variety of formats for approximate dates corresponds
      to the multitude of indicated aspects ("approximate",
      "uncertain", "unspecified", "significant", "hemispherical
      season") whose meanings and differences unfortunately remain
      unexplained.

   ∙  The standard specifies how users can agree on subsets of
      the features of ISO 8601 so that a reader of ISO 8601 data
      need not be able to understand all the formats
      ∘  a "profile" can be defined that lists features of ISO 8601,
         and "levels" within the profile can indicate subsets of
         the list, indicating the features that may be used in
         a communication
      ∘  an example profile, with the EDTF levels 0, 1, 2 is given
      ∘  the "mutual agreement" between communication partners
         (as posited in ISO 8601-1 for several features) is not
         addressed in a standardized profile. It requires
         parameterized features (eg, the number of additional
         digits in a year number) which are not provided in the
         proposed profiles

   ∙  ISO charges 336 CHF (about 336 US$) for the two parts with
      134 pages, that's about 7 bottles of a decent champagne.
      Think before you buy.

   Michael Deckers.


Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Michael H Deckers
    On 2019-04-07 08:47, K PALMEN asked:


> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?


    The standard does not specify the meanings of date
    notations with numbers 21..32 in the month field,
    nor does EDTF. There is one example in ISO 8601-2:2019,
    section 4.8.3:
         EXAMPLE 1  '2001-21' expresses "Spring of 2001"

    See [http://calndr-l.10958.n7.nabble.com
/Release-of-ISO-8601-1-2019-and-ISO-8601-2-2019-tp19558p19563.html]
    about what the standard has to say about seasons.


    Michael Deckers.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

k.palmen@btinternet.com
Dear Michael and Calendar People

I get the impression that parts of the standard are not defined well enough to be of use in practice. I think they may have been requested by someone influential who did not really know what they wanted.

Karl

Monday Beta April 2019

----Original message----
From : [hidden email]
Date : 07/04/2019 - 14:48 (BST)
To : [hidden email]
Subject : Re: new features of ISO 8601:2019

    On 2019-04-07 08:47, K PALMEN asked:


> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?


    The standard does not specify the meanings of date
    notations with numbers 21..32 in the month field,
    nor does EDTF. There is one example in ISO 8601-2:2019,
    section 4.8.3:
         EXAMPLE 1  '2001-21' expresses "Spring of 2001"

    See [http://calndr-l.10958.n7.nabble.com
/Release-of-ISO-8601-1-2019-and-ISO-8601-2-2019-tp19558p19563.html]
    about what the standard has to say about seasons.


    Michael Deckers.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Christoph Päper-2
K PALMEN:
>
> I get the impression that parts of the standard are not defined well enough to be of use in practice.
> I think they may have been requested by someone influential who did not really know what they wanted.

Yes, indeed. The EDTF additions in ISO 8601-2 are clearly intended for bibliographic purposes where you may encounter an issue labeled "Winter 2019" which you want to store in your database, but you won't know for sure whether that's Northern or Southern winter and, in the former case, whether it's the season ending or starting the year and also nothing about exact start and end dates (e.g. 15 November, 1 December, 21 December or 1 January) and hence length (e.g. 90 days, 91 days, 3 months, 13 weeks).

>> On 2019-04-07 08:47, K PALMEN asked:
>>
>>> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?

That would make sense, but EDTF uses 21..24 for {Spring, Summer, Autumn, Winter}, which obviously assumes that the year starts with spring. I tried to convince the people on the EDTF mailing list that this is against the spirit of ISO 8601, but unfortunately I failed and they could get it in unchanged (although other parts of EDTF, e.g. regarding letter symbols, have changed recently to accommodate ISO decisions).

Trimesters, quadmesters and semesters (3, 4 and 6 months, respectively) apparently only support starting the first one with January.

Fortunately, extension formats with letter prefixes (inspired by 'W' for ordinal weeks) such as 2019-Q2 are still available, although the iCalendar additions already burden a lot of meaning on (often arbitrary) letters as suffixes.

Unfortunately, there still seems to be no formal method and registration authority for Extensions that go beyond Profiles as defined in Chapter 15 of Part 2.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

k.palmen@btinternet.com
Dear Christoph and Calendar People

Thank you Christoph for making this clear.

Winter 2019 could be ambiguous in the Northern hemisphere and could refer to either the winter beginning in 2019 or the winter ending in 2019. An unambiguous form would be winter 2018/9 or winter 2019/20. I think ISO uses '/' for this purpose.

Karl

Tuesday Beta April 2019

----Original message----
From : [hidden email]
Date : 09/04/2019 - 10:19 (BST)
To : [hidden email]
Subject : Re: new features of ISO 8601:2019

K PALMEN:
>
> I get the impression that parts of the standard are not defined well enough to be of use in practice.
> I think they may have been requested by someone influential who did not really know what they wanted.

Yes, indeed. The EDTF additions in ISO 8601-2 are clearly intended for bibliographic purposes where you may encounter an issue labeled "Winter 2019" which you want to store in your database, but you won't know for sure whether that's Northern or Southern winter and, in the former case, whether it's the season ending or starting the year and also nothing about exact start and end dates (e.g. 15 November, 1 December, 21 December or 1 January) and hence length (e.g. 90 days, 91 days, 3 months, 13 weeks).

>> On 2019-04-07 08:47, K PALMEN asked:
>>
>>> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?

That would make sense, but EDTF uses 21..24 for {Spring, Summer, Autumn, Winter}, which obviously assumes that the year starts with spring. I tried to convince the people on the EDTF mailing list that this is against the spirit of ISO 8601, but unfortunately I failed and they could get it in unchanged (although other parts of EDTF, e.g. regarding letter symbols, have changed recently to accommodate ISO decisions).

Trimesters, quadmesters and semesters (3, 4 and 6 months, respectively) apparently only support starting the first one with January.

Fortunately, extension formats with letter prefixes (inspired by 'W' for ordinal weeks) such as 2019-Q2 are still available, although the iCalendar additions already burden a lot of meaning on (often arbitrary) letters as suffixes.

Unfortunately, there still seems to be no formal method and registration authority for Extensions that go beyond Profiles as defined in Chapter 15 of Part 2.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Walter J Ziobro
In reply to this post by Michael H Deckers

Dear Karl, Christophe et al

Perhaps ISO is moving toward standards for "vague" years Maybe it's possible to apply the new standards to accommodate the primitive Native American tradition of referring to years as "snows", months as "moons" and days as "sleeps"  But seriously, it seems that ISO wants to accommodate several conventions that are in actual widespread use, but that what they have produced is not a finished product, but a work still in process

Walter Ziobro




On Tuesday, April 9, 2019 Christoph Päper <[hidden email]> wrote:

K PALMEN:
>
> I get the impression that parts of the standard are not defined well enough to be of use in practice.
> I think they may have been requested by someone influential who did not really know what they wanted.

Yes, indeed. The EDTF additions in ISO 8601-2 are clearly intended for bibliographic purposes where you may encounter an issue labeled "Winter 2019" which you want to store in your database, but you won't know for sure whether that's Northern or Southern winter and, in the former case, whether it's the season ending or starting the year and also nothing about exact start and end dates (e.g. 15 November, 1 December, 21 December or 1 January) and hence length (e.g. 90 days, 91 days, 3 months, 13 weeks).


>> On 2019-04-07 08:47, K PALMEN asked:
>>
>>> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?


That would make sense, but EDTF uses 21..24 for {Spring, Summer, Autumn, Winter}, which obviously assumes that the year starts with spring. I tried to convince the people on the EDTF mailing list that this is against the spirit of ISO 8601, but unfortunately I failed and they could get it in unchanged (although other parts of EDTF, e.g. regarding letter symbols, have changed recently to accommodate ISO decisions).

Trimesters, quadmesters and semesters (3, 4 and 6 months, respectively) apparently only support starting the first one with January.

Fortunately, extension formats with letter prefixes (inspired by 'W' for ordinal weeks) such as 2019-Q2 are still available, although the iCalendar additions already burden a lot of meaning on (often arbitrary) letters as suffixes.

Unfortunately, there still seems to be no formal method and registration authority for Extensions that go beyond Profiles as defined in Chapter 15 of Part 2.

Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Jamison Painter
In reply to this post by Michael H Deckers
KARL:

Most calendars have issues with getting the seasons exactly right. The two that do not are the FRC and the Persian Solar Hijri Calendar, both of which rely on astronomical observation to determine when the Equinox occurs (Autumnal for the FRC, Vernal for the PSHC). And nowadays, one can even predict the occurrence of these many years in advance. And of course, there are tabular methods that work almost as well. But Autumn begins on 1 Vendemiaire. Winter begins on 1 Nivose. Spring begins on 1 Germinal. Summer begins on 1 Messidor. All those dates are accurate for the occurrence of the Equinoxes and the Solstices, if one is using astronomical observation as one's method for calculating the occurrence of the Autumnal or Vernal Equinoxes.

Regards,
Jamison

20 Germinal CCXXVII, Bee Hive.

K PALMEN <[hidden email]> wrote:

>Dear Christoph and Calendar People
>
>Thank you Christoph for making this clear.
>
>Winter 2019 could be ambiguous in the Northern hemisphere and could refer to either the winter beginning in 2019 or the winter ending in 2019. An unambiguous form would be winter 2018/9 or winter 2019/20. I think ISO uses '/' for this purpose.
>
>Karl
>
>Tuesday Beta April 2019
>
>----Original message----
>From : [hidden email]
>Date : 09/04/2019 - 10:19 (BST)
>To : [hidden email]
>Subject : Re: new features of ISO 8601:2019
>
>K PALMEN:
>>
>> I get the impression that parts of the standard are not defined well enough to be of use in practice.
>> I think they may have been requested by someone influential who did not really know what they wanted.
>
>Yes, indeed. The EDTF additions in ISO 8601-2 are clearly intended for bibliographic purposes where you may encounter an issue labeled "Winter 2019" which you want to store in your database, but you won't know for sure whether that's Northern or Southern winter and, in the former case, whether it's the season ending or starting the year and also nothing about exact start and end dates (e.g. 15 November, 1 December, 21 December or 1 January) and hence length (e.g. 90 days, 91 days, 3 months, 13 weeks).
>
>>> On 2019-04-07 08:47, K PALMEN asked:
>>>
>>>> Also are the seasons treated like weeks in that each year starts with the season that starts nearest to Jan 1 of the year?
>
>That would make sense, but EDTF uses 21..24 for {Spring, Summer, Autumn, Winter}, which obviously assumes that the year starts with spring. I tried to convince the people on the EDTF mailing list that this is against the spirit of ISO 8601, but unfortunately I failed and they could get it in unchanged (although other parts of EDTF, e.g. regarding letter symbols, have changed recently to accommodate ISO decisions).
>
>Trimesters, quadmesters and semesters (3, 4 and 6 months, respectively) apparently only support starting the first one with January.
>
>Fortunately, extension formats with letter prefixes (inspired by 'W' for ordinal weeks) such as 2019-Q2 are still available, although the iCalendar additions already burden a lot of meaning on (often arbitrary) letters as suffixes.
>
>Unfortunately, there still seems to be no formal method and registration authority for Extensions that go beyond Profiles as defined in Chapter 15 of Part 2.
Reply | Threaded
Open this post in threaded view
|

Re: new features of ISO 8601:2019

Christoph Päper-2
In reply to this post by k.palmen@btinternet.com
K PALMEN:
>
> Winter 2019 could be ambiguous in the Northern hemisphere and could refer to either the winter beginning in 2019 or the winter ending in 2019. An unambiguous form would be winter 2018/9 or winter 2019/20. I think ISO uses '/' for this purpose.

A forward slash separates beginning and end of a duration.

One (non-standard) way to specify astronomic Northern winter that starts in the previous year without a dedicated code would be a combination of 3-month-ish quarters and offset, e.g.:

 - 2019-Q1T+264:00
 - 2019-Q1T+264,0
 - 2019-Q1T+264.0
 - 2019-Q1T+264
 - 2019-Q1T+11;00
 - 2019-Q1T+11;
 - 2019-Q1T+11D
 - 2019-Q1@2018-12-21/2019-03-20
 - 2019-Q1@2018-12-21/P90D
 - 2019-Q1@P90D/2019-03-20