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

RE: [ISO8601] Are these problems relevant to ISO-8601

Expand Messages
  • Tex Texin
    I would rather people stated what they thought instead of throwing out articles and quotes and assuming we will infer what they are thinking. This collection
    Message 1 of 9 , Mar 1 3:31 AM
    • 0 Attachment
      
      I would rather people stated what they thought instead of throwing out articles and quotes and assuming we will infer what they are thinking.
      This collection of quotes is not compelling of anything.
      Yes, the world needs a standard. It doesn't need to be 8601 (although I would like it to be).
      The Tribble quote is not using 8601, but something similar.
       
      If you want to cite date problems, 8601 itself has a number of problems. Does that mean it shouldn't be the standard of choice?
       
      There is no conclusion to be drawn from this.
       
      tex
       

       

      From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of hjwoudenberg@...
      Sent: Tuesday, February 27, 2007 10:03 PM
      To: iso8601@yahoogroups.com
      Subject: [ISO8601] Are these problems relevant to ISO-8601

       “You wouldn’t believe how much time we wasted in the past doing things like reformatting dates for SQL statements, or converting COLeDateTimes (a cool date/time) to someOtherKindOfDate Time (some other kind of date/time).” Joel Spolsky¾ a founder of FogCreek software, author of the book Joel On Software.  For a programmer to export the December 26, 2006, to an Excel spreadsheet, the date must be converted it to the number 37,066.  Java, C/C++, Microsoft.NET, most programming languages have different numbers and even different versions have a different numbers.  This type of date/time is called incremental data/time.

       the only way to solve these date problems is for the industry to define a standard – not dependent on specific architecture ( 64-bit binary integer or floating point) and is the way dates are used (field based year, month, day, hours etc…, not incremental date/time).  1997 Tony Hampel¾ group manager at Sun Microsystems, An ounce of prevention. InfoWorld Publishing Company 1997.

      The only truly portable encoding is some form of representation of the date, such as "±CCYYMMDDhhmmssfffff f" (field-based date/time).  1999 David R. Tribble¾in the proposal for ISO C and C++ Extended-Range Time Type.  He is also the author of Incompatibilities Between ISO C and ISO C++,and in 2004 ISO C 200X Proposal: Calendar Date Functions, ISO C 200X Proposal: Time-zone Functions and ISO C 200X Proposal: Long Time Type.

       “People are often surprised why this feature cannot be supplied by Microsoft….” (Global any time zone to any time zone conversion). “However, there is agreement that this is a very important feature, and it is under serious consideration for the next release.” MSDN Visual Studio 2005.

      “extendsions to time zone support is one of the most requested features.” Microsoft MSDN Blog, June 2006.

       

      hjw





      AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

    • hjwoudenberg@aol.com
      In a message dated 3/1/2007 5:32:09 A.M. Central Standard Time, tex@yahoo-inc.com writes: There is no conclusion to be drawn from this. My conclusion
      Message 2 of 9 , Mar 1 9:45 AM
      • 0 Attachment
        In a message dated 3/1/2007 5:32:09 A.M. Central Standard Time, tex@... writes:
        There is no conclusion to be drawn from this.
         
        My conclusion
        Microsoft Word succeded because it was easier to use
        .
        WordPerfect had more features.
         
        Making ISO-8601 easier o use is importatn.
         
        hjw




        AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
      • Tex Texin
        Interesting. I didn t see either product mentioned in the mail. _____ From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of
        Message 3 of 9 , Mar 2 12:55 AM
        • 0 Attachment
          Interesting. I didn't see either product mentioned in the mail.
           


          From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of hjwoudenberg@...
          Sent: Thursday, March 01, 2007 9:45 AM
          To: ISO8601@yahoogroups.com
          Subject: Re: [ISO8601] Are these problems relevant to ISO-8601

          In a message dated 3/1/2007 5:32:09 A.M. Central Standard Time, tex@yahoo-inc. com writes:
          There is no conclusion to be drawn from this.
           
          My conclusion
          Microsoft Word succeded because it was easier to use
          .
          WordPerfect had more features.
           
          Making ISO-8601 easier o use is importatn.
           
          hjw

          .

        • hjwoudenberg@aol.com
          In a message dated 3/2/2007 2:56:15 A.M. Central Standard Time, tex@yahoo-inc.com writes: Interesting. I didn t see either product mentioned in the mail. I
          Message 4 of 9 , Mar 2 2:31 AM
          • 0 Attachment
            In a message dated 3/2/2007 2:56:15 A.M. Central Standard Time, tex@... writes:
            Interesting. I didn't see either product mentioned in the mail.
             
            I believe:
                ISO-8601 will become popular when software makes it is easy to use.
                ISO-8601 requires range and precision specifications.
             
             History
                IEE-754 was an instant success it had details on range and precision.
                IEE-874 total failure and had not details on range and precision.
                IEE-754-r, every language is rushing to support it.  It provides detail missing rom IEE-874
             
            Supported by
             

            Standardization is important. 

            A program or a database is ISO-8601 compliant if the date/time is:

            ±002000-03-01T13:15:45.999999-02”

            ±002000-03-01T13:15:45.999999-02:00”

            ±002000-03-01T13:15:45,999999-02”

            ±002000-03-01T13:15:45,999999-02:00”

            ±002000-03-01t13:15:45.999999-02:00”

             

            ±2000-03-01T13:15:45.999999-02”

            ±2000-03-01T13:15:45.999999-02:00”

            ±2000-03-01T13:15:45,999999-02”

            ±2000-03-01T13:15:45,999999-02:00”

            ±2000-03-01t13:15:45.999999-02:00”

             

            ±20000301T131545.999999-02”

            ±20000301T131545.999999-02:00”

            ±20000301T131545,999999-02”

            ±20000301T131545,999999-02:00”

            ±20000301t131545.999999-02:00”

             

            ±20000301131545.999999-02”

            ±20000301131545.999999-0200”

            ±20000301131545,999999-02”

            ±20000301131545,999999-0200”

             

            Do you see no problem with this?

             

            There should be a standard!

            Eliminate the problem of Big “T” and little “t”

            Eliminate the problem of a comma “,” or a stop “.”

            Eliminate slow parsing, fixed format.

             

            ±0020000301131545999999-0200”

            ±0020000301131545999-0200”

            ±0020000301131545-0200”

             

            ±0020000301131545999999Z”

            ±0020000301131545999Z”

            ±0020000301131545Z”

             

            ±0020000301131545999999”

            ±0020000301131545999”

            ±0020000301131545”

             

            Fractions of seconds can be any size, it is terminated by a “Z” “+” “-“ or a blank.

             

             

             

             

             hjw





            AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
          • piebaldconsult
            ISO 8601 doesn t apply to internal representations, whether in memory or in a binary file. ISO 8601 limits neither range nor precision; both can by unlimited.
            Message 5 of 9 , Mar 2 6:13 AM
            • 0 Attachment
              ISO 8601 doesn't apply to internal representations, whether in memory
              or in a binary file.

              ISO 8601 limits neither range nor precision; both can by unlimited.
            • hjwoudenberg@aol.com
              In a message dated 3/2/2007 8:49:54 A.M. Central Standard Time, PIEBALDconsult@aol.com writes: ISO 8601 doesn t apply to internal representations, whether in
              Message 6 of 9 , Mar 2 6:49 PM
              • 0 Attachment
                In a message dated 3/2/2007 8:49:54 A.M. Central Standard Time, PIEBALDconsult@... writes:

                ISO 8601 doesn't apply to internal representations, whether in memory
                or in a binary file.

                ISO 8601 limits neither range nor precision; both can by unlimited.

                __._,_._had__
                For decimal data.
                EEE-864  "limits neither range nor precision; both can by unlimited"
                EEE-754 revision has range and precision, internal representation, every language is rushing to implement it.  
                 
                As the saying goes, when you try to be everything for everybody, you are nothing for anyone.




                AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
              • piebaldconsult
                ... memory ... every ... It seems we go through this every couple of months. I believe you are bemoaning the absence of a standard _internal_ representation
                Message 7 of 9 , Mar 3 7:55 AM
                • 0 Attachment
                  > ISO 8601 doesn't apply to internal representations, whether in
                  memory
                  > or in a binary file.
                  >
                  > ISO 8601 limits neither range nor precision; both can by unlimited.

                  > For decimal data.
                  > EEE-864 "limits neither range nor precision; both can by unlimited"
                  > EEE-754 revision has range and precision, internal representation,
                  every
                  > language is rushing to implement it.

                  It seems we go through this every couple of months. I believe you are
                  bemoaning the absence of a standard _internal_ representation for
                  temporal data, which has _absolutely_nothing_ to do with ISO 8601.

                  Go devise one and report back. (Now I'll have to dig through this big
                  stack of notes to find mine.)
                • datefreak
                  Please, PLEASE, ladies and gentlemen! What is this discussion group all about? Could ALL of us please read the introdution to ISO 8601 once again? It s all
                  Message 8 of 9 , Mar 6 3:35 PM
                  • 0 Attachment
                    Please, PLEASE, ladies and gentlemen!
                    What is this discussion group all about?
                    Could ALL of us please read the introdution to ISO 8601 once again?

                    It's all about REPRESENTATION of data elements. So: NOT, i repeat:
                    NOT, about programming (and any associated problemms derived from
                    that).
                    Thus, Piebald is absolutely right.

                    So please refrain from all programming jazz and/or any comments that
                    have NOTHING AT ALL to do with the intention of ISO 8601, and stick
                    to what ISO 8601 is REALLY MEANT FOR. That would make life very much
                    easier for all of us!

                    Regards,
                    Jan Sax


                    --- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
                    wrote:
                    >
                    > > ISO 8601 doesn't apply to internal representations, whether in
                    > memory
                    > > or in a binary file.
                    > >
                    > > ISO 8601 limits neither range nor precision; both can by
                    unlimited.
                    >
                    > > For decimal data.
                    > > EEE-864 "limits neither range nor precision; both can by
                    unlimited"
                    > > EEE-754 revision has range and precision, internal
                    representation,
                    > every
                    > > language is rushing to implement it.
                    >
                    > It seems we go through this every couple of months. I believe you
                    are
                    > bemoaning the absence of a standard _internal_ representation for
                    > temporal data, which has _absolutely_nothing_ to do with ISO 8601.
                    >
                    > Go devise one and report back. (Now I'll have to dig through this
                    big
                    > stack of notes to find mine.)
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.