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

Would appreciate Tex Texins comments on this.

Expand Messages
  • hjwoudenberg@aol.com
    ISO-8601 5.4 Quote NOTE By Mutual agreement of the partners in information interchange, the character (T) may be omitted... From this I understand that the
    Message 1 of 3 , Mar 1, 2005
      ISO-8601  5.4
      Quote "NOTE By Mutual agreement of the partners in information interchange, the character (T) may be omitted..."
       
      From this I understand that the basic format:
      "YYYYMMDDhhmmss" is legal
       
      However, I don't see that the comma or period (stop) may be dropped with sub-seconds.
      In other words only:
      "YYYYMMDDhhmmss.sss" is a legitimate format.  Dropping the comma or period is not.
       
      Would appreciate responses from those who knows ISO-8601 better than I do.
       
      hjwoudenberg
       
       
    • John Steele
      5.3.1.3 (of 2000-12-19 draft) states: . . . and the decimal fraction shall be divided from the integer part by the decimal sign . . . and goes on to allow
      Message 2 of 3 , Mar 1, 2005
        5.3.1.3 (of 2000-12-19 draft) states:
        ". . . and the decimal fraction shall be divided from the integer part by the decimal sign . . ." and goes on to allow (.) or (,).
         
        With a "shall be," you will need to find a specific exception phrase in the text or you are SOL. Of course, "legitimate" and "ISO8601 compliant" are not the same thing. Many non-8601formats are still accepted and used.
         
        Why the quest for ever more arcane and (human) unreadable formats? I feel the standard already contains too many such and that hampers its acceptance.
         
        If it is only for computers, a single unit, whether Julian days or Unix tics, would be a preferred format. If it is intended for human readability as well as computer interchange, some separators to make it readable are vital. The 5-6 characters you are saving aren't worth it.  While the "basic" format does not have separators, it is a bad idea. It may not be so bad for date alone or time alone, but in a date-time string, it virtually guarentees human readability problems. When a human can't read it and has to, he says "this is asinine" and rejects it.
         
        I'm not a consultant and if a client is pushing for a bad format, maybe you can't say it quite that strongly, but I think it is important to convey in some way. If the format is also supposed to be human-readable, human factors need to be considered not just the "letter of the law" in the standard.

        hjwoudenberg@... wrote:
        ISO-8601  5.4
        Quote "NOTE By Mutual agreement of the partners in information interchange, the character (T) may be omitted..."
         
        From this I understand that the basic format:
        "YYYYMMDDhhmmss" is legal
         
        However, I don't see that the comma or period (stop) may be dropped with sub-seconds.
        In other words only:
        "YYYYMMDDhhmmss.sss" is a legitimate format.  Dropping the comma or period is not.
         
        Would appreciate responses from those who knows ISO-8601 better than I do.
         
        hjwoudenberg
         
         

      • hjwoudenberg@aol.com
        In a message dated 3/1/2005 8:03:56 A.M. Central Standard Time, johnmsteele@yahoo.com writes: If it is only for computers, a single unit, whether Julian days
        Message 3 of 3 , Mar 1, 2005
          In a message dated 3/1/2005 8:03:56 A.M. Central Standard Time, johnmsteele@... writes:
          If it is only for computers, a single unit, whether Julian days or Unix tics, would be a preferred format.
          They cannot handle the date range and the level of fraction of seconds I want, even though I have a 64-bit computer.
           
          They are not user friendly as explained below:

          SQL¾Before you can effectively query date/time data, you have to know something about how date/time values are stored, (since they are stored as binary integers). SQL Server by Bryan Syverson, author of Murach’s SQL for SQL Server

        Your message has been successfully submitted and would be delivered to recipients shortly.