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

197[ISO8601] Re: Clarifications: 5.2.2.2

Expand Messages
  • g1smd@amsat.org
    Aug 1, 2001
      On 2001-Jul-16 Pete Forman wrote:


      [2001-Aug-01]



      >> In fact, the standard before the first truncated format in the
      >> opening paragraph of 5.2.1.3 says "In each case hyphens that
      >> indicate components should be used only as indicated or shall be
      >> omitted."

      >> That to me hints that some of choices are arbitrary, so don't play
      >> around with them. Also, there is no place that states that all
      >> formats are mutually unambiguous from each other. As I was reading
      >> I was looking for just such a statement or examples that violated
      >> the idea. I found neither, but that is no proof.

      > How about the last paragraph in 4.1.

      I agree with that. I didn't find the words '*mutually* unambiguous'.
      Instead, I found '... unique and unambiguous', which I think just
      about does the same job.



      > I agree that the choices seem arbitrary. There may be some logic
      > behind it though. My guess is that the rules are something like

      > Replace an omitted component in a truncated format with a hyphen.
      > Component may be century (first two digits of a four digit year)
      > or decade (first three digits of a four digit year) or last two
      > digits of the year or month or week. The term component is not
      > defined as such but the components are listed for each of the
      > truncated representations.

      Not quite. I think that you appear to say that -1 is a year like
      1981 or 2001, stated by omitting the decade. Adding the month to
      this, to increase precision, will make -111. This can now be
      confused with -DDD, day 111 of the year. So, you should modify
      your statement to say that: (except for Day of Year [DDD] elements,
      and Day of Week [D] elements) elements should always have an even
      number of digits: YYYY, YYMM, MMDD, YYMMDD, etc. However, I can
      see where you may have got this idea from. In the examples for
      the various 'Week-of-Year and Day-of-Week' formats, there are
      some three and some single digit year examples. However, in those
      examples, the placement of the 'W' always clarifies what is going
      on. In the Calendar and Ordinal date formats you cannot do this
      with Basic Formats. The Year must be two or four digits, except
      for some Extended Format dates that can have a three or single
      digit year, because these cannot be mixed up with other formats:
      -Y-DDD -YYY-DDD -Y-MM-DD -YYY-MM-DD and possibly -Y-MM and
      -YYY-MM (and you can probably omit the leading hyphen on all
      of these and get away with it). For most of these it is *not*
      possible to have a Basic format (if 'Basic' formats are taken
      to mean that hyphen separators *between* digits are omitted),
      as these *will* then be confused with other pre-defined formats.



      > Remove hyphens if the result is unambiguous.
      > 4.6 para 1 states that a hyphen may be necessary to represent
      > an omitted component. That implies to me that the hyphen
      > should not be used if possible.

      This 'ruling' seems arbitrary in the standard. A format like
      12-12 isn't permitted at all, but 121212 is read as YYMMDD,
      when I would expect YYYYMM to be the one. Similarly -121212
      doesn't appear anywhere, when I think that -YYMMDD is expected
      (like -1212 is -YYMM, for example).



      > (The above two rules may also be expressed as: Components may
      > be omitted, if the result is ambiguous then use a hyphen to
      > stand for the omitted component.)

      I almost agree with this, but I still don't understand why
      121212 has to be YYMMDD, when YYYYMM would be more logical,
      and this would then follow a 'pattern' with the other formats.
      See the various tables that I included in my previous message,
      posted 2001-Jul-16.



      > Add hyphens where a format is ambiguous. This is bound to be
      > arbitrary: if two formats collide one must be chosen to get
      > the extra hyphen.

      It isn't always arbitrary. '12' is always the first two digits
      of a Year, so the last two digits of the Year are -12, the Month
      is --12, and the Day is ---12. This is clear and logical. Note
      that 12-12 isn't permitted at all, as it could be either YY-MM
      or MM-DD. Instead -YY-MM and --MM-DD are used; so none of them
      'get the extra hyphen' (in this context)... they both include a
      hyphen or hyphens. So, two formats collide at '12-12' and rather
      then one gets a hyphen, and the other doesn't, then in fact the
      '12-12' format isn't defined/used at all.



      > Note that omitting hyphens by these rules is a separate issue to
      > 5.2.1.3. I take the latter to mean that the communicating parties
      > agree that, for example, two digits alone mean a month rather than
      > using four characters of 5.2.1.3.e proper.

      Yes, by mutual agreement I can say that '12' in one data element
      is MM, and in another is DD, rather than the default of YY.



      What comments have you got regarding the material in my message
      dated 2001-Jul-16, under the heading 'A BIG MISTAKE'?



      Cheers,

      Ian.


      <mail://g1smd@...>

      <http://www.qsl.net/g1smd/>
      <http://home.freeuk.net/g1smd/>
      <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>

      <ftp://ftp.funet.fi/pub/ham/misc/g1smd.zip>
      <ftp://ftp.qsl.net/pub/g1smd/>


      [2001-08-01]

      .end
    • Show all 15 messages in this topic