Loading ...
Sorry, an error occurred while loading the content.

190Re: [ISO8601] Re: Clarifications: 5.2.2.2

Expand Messages
  • Pete Forman
    Jul 17, 2001
      g1smd@... writes:
      > [most of the material snipped]

      > I agree that this is a bit sloppy. It needs rewriting, or some
      > additional notes. The minimum required, would be to state that the
      > year may be specified by two, or by four, or by more digits; and I
      > see a problem here... 121212 is assumed to be YYMMDD, but this
      > could be the YYYYYY 121212.

      No, were an expanded representation to be used for a six digit year it
      would be +121212.


      > Also, the 'mutual agreement' problem appears here again.
      > Representations that have the prescribed leading hyphens omitted
      > can be used only by mutual agreement... except that the format at j
      > seems to be the default, rather than the format stated in i. That
      > is, for all the others, mutual agreement is required, but for j it
      > has already been forced upon us to agree to this. In doing this,
      > you get the 'logic error' with the RIGHT c entry being disallowed
      > (in order to satisfy the {non written, as far as I can see} rule
      > that any representation can have only one implied meaning unless
      > mutual agreement has already been obtained).

      As I said in my previous message I consider that there are two
      possible reasons for omitting hyphens. Mutual agreement is one. The
      other is that hyphens should/must only be used to stand for omitted
      components in order to disambiguate.


      > I guess they had to include YYMMDD and exclude YYYYMM simply
      > because millions of computer systems were already using YYMMDD.

      Not necessarily. We are talking about a date format, it is reasonable
      to give preference to the full precision interpretation over the
      reduced one.

      In general ISO 8601 does not say that two digit years are evil. It
      passes them off as a specific case of a truncated representation.

      > The table can be rearranged to ask what a numerical format should
      > be decoded as. To keep it simple, I have not divided it into Basic
      > and Extended formats. Anything with a hyphen between elements is an
      > Extended format.

      As you probably realise, that contradicts 5.2.1.2.

      > Writing the table this way, I have included some formats that the
      > ISO standard says are 'Not Applicable'. There cannot be a way to
      > tell if '1950' is supposed to be a Basic format Year or an Extended
      > format Year. I have ignored this and included it under both styles.

      Again, the standard is clear that '1950' is basic format only. I take
      'Not Applicable' to mean "don't use this".




      What we could do with is a rationale for the standard. I wonder if
      one was produced.

      The other useful production would be a general reader. Given any
      input string it should be possible to determine whether it is basic or
      extended, full or reduced precision, expanded or not, truncated or
      not, calendar or ordinal or week. (At a higher level we need to
      determine whether a string is a date, time, interval, etc.)

      A start for this might be

      Parse as date:
      Does it contain a 'W'?
      => parse as week date
      else Does it have an even number of digits? **
      => parse as calendar date
      else
      => parse as ordinal date

      Parse as calendar date:
      Split into fields of hyphen or pair-of-digits or plus (1st only)
      Match against candidate formats

      Parse as ordinal date:
      Split into fields of hyphen or pair-of-digits or plus (1st only)
      or triple-of-digits (last only)
      Match against candidate formats

      **This assumes that expanded formats use an even number of digits for
      the year. A different approach might tolerate an odd number.
      Actually, in order to parse expanded formats the number of digits
      for the year must be known otherwise there is no way to distinguish
      days from years from centuries. Years before 0000 are problematic
      as well. But according to 4.3.2.1 mutual agreement is needed for
      years prior to 1582 anyway.

      The table for calendar dates then starts

      Number of Fields Format Section Note
      fields
      1 + illegal
      1 - illegal
      1 2 YY 5.2.1.2.c.B
      2 + - illegal
      2 + 2 +YY 5.2.1.4.d.B 1
      2 - - illegal
      2 - 2 -YY 5.2.1.3.c.B 2
      2 2 - illegal
      2 2 2 YYYY 5.2.1.2.b.B
      ...
      4 2 2 2 2 YYYYMMDD 5.2.1.1.B
      ...
      6 2 2 - 2 - 2 YYYY-MM-DD 5.2.1.1.E

      Notes:
      1 Implicitly assume that expanded representation years have 4 digits
      2 Implicitly assume that expanded representation years are positive
      or have more that 4 digits


      Different versions of tables would be needed for different expanded
      representations. Expanded and truncated representations are mutually
      exclusive. The agreement between parties has to be inspected to
      establish whether a leading hyphen means a negative year or truncated
      representation.
      --
      Pete Forman -./\.- Disclaimer: This post is originated
      WesternGeco -./\.- by myself and does not represent
      pete.forman@... -./\.- opinion of Schlumberger, Baker
      http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
    • Show all 15 messages in this topic