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

Fwd: Must do away with time "24:00:00"

Expand Messages
  • hjwoudenberg@aol.com
    The ISO-8601 idea that 1999-12-31T24:00:00 = 2000-01-01T00:00:00 is not workable. The standard must be changed. Example of the problems with UNIX time zone.
    Message 1 of 10 , Dec 4, 2003
    • 0 Attachment


      The ISO-8601 idea that 1999-12-31T24:00:00 = 2000-01-01T00:00:00 is not workable.  The standard must be changed.  Example of the problems with UNIX time zone.

      Herman


      Here are proposed change to the time zone package. Included:
        * corrections of the spelling of UNIX and of its trademark holder.
        * correct version number in iso3166.tab
        * normalize format of comments in localtime.c
        * change mktime to search temporally backward through used time
         corrections when making DST adjustments
        * change Makefile to generate text versions of man pages
         and to check for uses of 24:00 in input files

        * change northamerica to avoid use of 24:00
         and to normalize a date appearing in a comment

        * add workman.sh script for generating text versions of man pages
        * change zic.c to warn about use of 24:00 if the -v option is used
        * change zic.8 to document warnings about 24:00



    • NGUYEN Adam
      Hello. Why should North America avoid the use of 24:00:00 ? The end of one day is the beginning of the next. It makes sense. If you are talking about file
      Message 2 of 10 , Dec 5, 2003
      • 0 Attachment
                 Hello. Why should North America avoid the use of "24:00:00"? The end of one day is the beginning of the next. It makes sense. If you are talking about file modification times, 24:00 should not exist there, as a file is modified either at one time or another. I heard that those times can be accurate to 0.01 second. Taking that into account, the limits should be 23:59:59.99 and 00:00:00.00, no "24:00:00" in there.

        At 2003-12-04 22:31 (UTC -0500), you wrote:



        The ISO-8601 idea that 1999-12-31T24:00:00 = 2000-01-01T00:00:00 is not workable.  The standard must be changed.  Example of the problems with UNIX time zone.

        Herman

        Here are proposed change to the time zone package. Included:
          * corrections of the spelling of UNIX and of its trademark holder.
          * correct version number in iso3166.tab
          * normalize format of comments in localtime.c
          * change mktime to search temporally backward through used time
           corrections when making DST adjustments
          * change Makefile to generate text versions of man pages
           and to check for uses of 24:00 in input files

          * change northamerica to avoid use of 24:00
           and to normalize a date appearing in a comment

          * add workman.sh script for generating text versions of man pages
          * change zic.c to warn about use of 24:00 if the -v option is used
          * change zic.8 to document warnings about 24:00



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



        Return-path: <HJWOUDENBERG@...>
        From: HJWOUDENBERG@...
        Full-name: HJWOUDENBERG
        Message-ID: <78.4beb51b4.2d00f2ae@...>
        Date: Thu, 4 Dec 2003 15:27:26 EST
        Subject: This time zone package has been around for years. 
        To: KIDS@...
        MIME-Version: 1.0
        X-Mailer: 8.0 for Windows sub 6024
        Content-Type: multipart/alternative; x-avg-checked=avg-ok-5F4041F1; boundary=part2_18b.230bd265.2d00f2ae_boundary

        Appears that people are starting to use it.  Competition for me.  Mine is much more comprehensive.

        Here are proposed change to the time zone package. Included:
            * corrections of the spelling of UNIX and of its trademark holder.
            * correct version number in iso3166.tab
            * normalize format of comments in localtime.c
            * change mktime to search temporally backward through used time
              corrections when making DST adjustments
            * change Makefile to generate text versions of man pages
              and to check for uses of 24:00 in input files
            * change northamerica to avoid use of 24:00
              and to normalize a date appearing in a comment
            * add workman.sh script for generating text versions of man pages
            * change zic.c to warn about use of 24:00 if the -v option is used
            * change zic.8 to document warnings about 24:00


        ---
        Incoming mail is certified Virus Free.
        Checked by AVG anti-virus system (http://www.grisoft.com).
        Version: 6.0.542 / Virus Database: 336 - Release Date: 2003-11-18
      • Budai, Andrew
        ... From: NGUYEN Adam To: ISO8601@yahoogroups.com Sent: 2003 12 06, Saturday 00:35 Subject: Re: [ISO8601] Fwd: Must do away with time 24:00:00 Hello. Why
        Message 3 of 10 , Dec 5, 2003
        • 0 Attachment
           
          ----- Original Message -----
          Sent: 2003 12 06, Saturday 00:35
          Subject: Re: [ISO8601] Fwd: Must do away with time "24:00:00"

                   Hello. Why should North America avoid the use of "24:00:00"? The end of one day is the beginning of the next. It makes sense. If you are talking about file modification times, 24:00 should not exist there, as a file is modified either at one time or another. I heard that those times can be accurate to 0.01 second. Taking that into account, the limits should be 23:59:59.99 and 00:00:00.00, no "24:00:00" in there.

          I not only agree with the above opinion, but I also want to add that most people, who are affected by the date and time mode described in ISO 8601, are not Unix or other program operators, but ordinary calendar and clock users. 
           
          A globally acceptable uniformity in telling the time and dates is imperative.  For that purpose, we should embrace the basic concept.  Refinements for special applications can be added as the requirements of each user varies.  However, we should keep in mind: the basic idea is to let a new generation of ordinary people develop an English language that is unambiguous, common to all, and easy to use.
           
          BUDAI  Andrew — Taiwan
        • Gilbert Healton
          As I have seen a fair amount of confusion in others on how to handle 24:00:00, thus like avoiding it in most cases. The only exception is using it as a
          Message 4 of 10 , Dec 5, 2003
          • 0 Attachment
            As I have seen a fair amount of confusion in others on how to handle
            24:00:00, thus like avoiding it in most cases. The only exception is
            using it as a completion time that all events have completed by. Used
            only for events finished on or BEFORE 23:59:59,99... (23:59:60,99....
            on leap second days). As all events are done by 24:00:00 (or
            00:00:00) no part of the event spans a day boundry.


            --- In ISO8601@yahoogroups.com, "Budai, Andrew" <bandi@m...> wrote:
            >
            > ----- Original Message -----
            > From: NGUYEN Adam
            > To: ISO8601@yahoogroups.com
            > Sent: 2003 12 06, Saturday 00:35
            > Subject: Re: [ISO8601] Fwd: Must do away with time "24:00:00"
            >
            >
            > Hello. Why should North America avoid the use
            of "24:00:00"? The end of one day is the beginning of the next. It
            makes sense. If you are talking about file modification times, 24:00
            should not exist there, as a file is modified either at one time or
            another. I heard that those times can be accurate to 0.01 second.
            Taking that into account, the limits should be 23:59:59.99 and
            00:00:00.00, no "24:00:00" in there.
            >
            >
            > --------------------------------------------------------------------
            ----------
            >
            > I not only agree with the above opinion, but I also want to add
            that most people, who are affected by the date and time mode
            described in ISO 8601, are not Unix or other program operators, but
            ordinary calendar and clock users.
            >
            > A globally acceptable uniformity in telling the time and dates is
            imperative. For that purpose, we should embrace the basic concept.
            Refinements for special applications can be added as the requirements
            of each user varies. However, we should keep in mind: the basic idea
            is to let a new generation of ordinary people develop an English
            language that is unambiguous, common to all, and easy to use.
            >
            > BUDAI Andrew - Taiwan
            > --------------------------------------------------------------------
            ----------
          • NGUYEN Adam
            Yes, Budai! The full format should really be YYYY-MM-DD hh:mm:ss (no T in the middle, as that will cause confusion). Even YYYY/MM/DD hh:mm:ss is fine for me,
            Message 5 of 10 , Dec 5, 2003
            • 0 Attachment
                       Yes, Budai! The full format should really be YYYY-MM-DD hh:mm:ss (no T in the middle, as that will cause confusion). Even YYYY/MM/DD hh:mm:ss is fine for me, as that's the way I used to do it and it's still doen that way in Japan and other places. The / can cause problems with computer file names so, that's why I changed my habits to using athe hyphen (-) and for ranges, the double-hyphen (--).

              At 2003-12-06 01:28 (UTC +0800), you wrote:

                      
               
              ----- Original Message -----
              From: NGUYEN Adam
              To: ISO8601@yahoogroups.com
              Sent: 2003 12 06, Saturday 00:35
              Subject: Re: [ISO8601] Fwd: Must do away with time "24:00:00"

                      Hello. Why should North America avoid the use of "24:00:00"? The end of one day is the beginning of the next. It makes sense. If you are talking about file modification times, 24:00 should not exist there, as a file is modified either at one time or another. I heard that those times can be accurate to 0.01 second. Taking that into account, the limits should be 23:59:59.99 and 00:00:00.00, no "24:00:00" in there.
              I not only agree with the above opinion, but I also want to add that most people, who are affected by the date and time mode described in ISO 8601, are not Unix or other program operators, but ordinary calendar and clock users. 
               
              A globally acceptable uniformity in telling the time and dates is imperative.  For that purpose, we should embrace the basic concept.  Refinements for special applications can be added as the requirements of each user varies.  However, we should keep in mind: the basic idea is to let a new generation of ordinary people develop an English language that is unambiguous, common to all, and easy to use.
               
              BUDAI  Andrew — Taiwan
              Incoming mail is certified Virus Free.
              Checked by AVG anti-virus system (http://www.grisoft.com).
              Version: 6.0.542 / Virus Database: 336 - Release Date: 2003-11-18
            • NGUYEN Adam
              Yes, the ONLY time 24 h, 24:00, or 24:00:00 is used is to mean an event ending time (eg. The party goes from 18:00 - 24:00). ... Outgoing mail is certified
              Message 6 of 10 , Dec 5, 2003
              • 0 Attachment
                         Yes, the ONLY time 24 h, 24:00, or 24:00:00 is used is to mean an event ending time (eg. The party goes from 18:00 - 24:00).

                At 2003-12-05 19:38 (UTC +0000), you wrote:


                As I have seen a fair amount of confusion in others on how to handle
                24:00:00, thus like avoiding it in most cases. The only exception is
                using it as a completion time that all events have completed by. Used
                only for events finished on or BEFORE 23:59:59,99... (23:59:60,99....
                on leap second days).  As all events are done by 24:00:00 (or
                00:00:00) no part of the event spans a day boundry.


                --- In ISO8601@yahoogroups.com, "Budai, Andrew" <bandi@m...> wrote:
                >
                >   ----- Original Message -----
                >   From: NGUYEN Adam
                >   To: ISO8601@yahoogroups.com
                >   Sent: 2003 12 06, Saturday 00:35
                >   Subject: Re: [ISO8601] Fwd: Must do away with time "24:00:00"
                >
                >
                >           Hello. Why should North America avoid the use
                of "24:00:00"? The end of one day is the beginning of the next. It
                makes sense. If you are talking about file modification times, 24:00
                should not exist there, as a file is modified either at one time or
                another. I heard that those times can be accurate to 0.01 second.
                Taking that into account, the limits should be 23:59:59.99 and
                00:00:00.00, no "24:00:00" in there.
                >
                >
                > --------------------------------------------------------------------
                ----------
                >
                >   I not only agree with the above opinion, but I also want to add
                that most people, who are affected by the date and time mode
                described in ISO 8601, are not Unix or other program operators, but
                ordinary calendar and clock users. 
                >
                >   A globally acceptable uniformity in telling the time and dates is
                imperative.  For that purpose, we should embrace the basic concept. 
                Refinements for special applications can be added as the requirements
                of each user varies.  However, we should keep in mind: the basic idea
                is to let a new generation of ordinary people develop an English
                language that is unambiguous, common to all, and easy to use.
                >
                >   BUDAI  Andrew - Taiwan
                > --------------------------------------------------------------------
                ----------


                ------------------------ Yahoo! Groups Sponsor ---------------------~-->
                Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
                Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
                http://www.c1tracking.com/l.asp?cid=5511
                http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/1U_rlB/TM
                ---------------------------------------------------------------------~->

                 

                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                ---
                Incoming mail is certified Virus Free.
                Checked by AVG anti-virus system (http://www.grisoft.com).
                Version: 6.0.542 / Virus Database: 336 - Release Date: 2003-11-18
              • piebaldconsult
                No, there is no such beast as 24:00:00. JB
                Message 7 of 10 , Dec 5, 2003
                • 0 Attachment
                  No, there is no such beast as 24:00:00.

                  JB
                • Budai, Andrew
                  ... From: piebaldconsult To: ISO8601@yahoogroups.com Sent: 2003 December 06, Saturday 08:54 Subject: [ISO8601] Re: Fwd: Must do away with time 24:00:00 No,
                  Message 8 of 10 , Dec 5, 2003
                  • 0 Attachment
                     
                    ----- Original Message -----
                    Sent: 2003 December 06, Saturday 08:54
                    Subject: [ISO8601] Re: Fwd: Must do away with time "24:00:00"

                    No, there is no such beast as 24:00:00.

                    JB

                    In Taiwan, the traffic signs are a mix of traditional Chinese writing and the internationally understood picture signs.  One never knows what is what, even the locals don't always know what how to interpret them.  However, there is an interesting tab added to some
                    No Left Turn signs:     0 ~ 24       This seems to simplify or making quite clear the ban on left turning: ALL THE TIME.  In the U,S,, we use 24/7 to express something continuously happening or being in effect.  Denny's coffee shops used to simply say. ALWAYS OPEN.  However, this 0 ~ 24 sign seems simple enough to carry the message on traffic signs. 

                    B., Andrew

                  • Ed Davies
                    ... This is a strange thing to say in a group dedicated to discussion of ISO 8601. ISO 8601:2000(E) says: # 5.3.2 Midnight # # The complete representations in
                    Message 9 of 10 , Dec 6, 2003
                    • 0 Attachment
                      piebaldconsult wrote:
                      >
                      > No, there is no such beast as 24:00:00.
                      >
                      > JB


                      This is a strange thing to say in a group dedicated to discussion of ISO 8601.

                      ISO 8601:2000(E) says:

                      # 5.3.2 Midnight
                      #
                      # The complete representations in basic and extended format for midnight, in
                      # accordance with 5.3.1, shall be expressed in either of the two following ways:
                      #
                      # Basic format Extended format
                      # a) 000000 00:00:00 (the beginning of a day);
                      # b) 240000 24:00:00 (the end of a day).
                      #
                      # The representations may be reduced in accordance with 5.3.1.2, truncated in
                      # accordance with 5.3.1.4 or designated to be a time expression in accordance
                      # with 5.3.1.5. To represent midnight the representations may be expanded with
                      # a decimal fraction containing only zeros in accordance with 5.3.1.3.
                      #
                      # NOTE 1 Midnight will normally be represented as [0000] or [2400].
                      #
                      # NOTE 2 The choice of representation a) or b) will depend upon any association
                      # with a date, or a time-interval. Representations where [hh] has the
                      # value [24] are only preferred to represent the end of a time-interval
                      # in accordance with 5.5.1.
                      #
                      # NOTE 3 The end of one day [2400] coincides with [0000] at the start of the next
                      # day, e.g. 2400 on 1985 April 12 is the same as 0000 on 1985 April 13. If
                      # there is no association with a date or a time-interval both a) and b)
                      # represent the same clock time in the 24-hour timekeeping system.

                      Clearly, the authors of ISO 8601 intended that there should be such a beast
                      as 24:00:00.

                      There's lots of room for discussion as to when it is a good idea to use this
                      form but I would suggest that, for example, any program which claims to read
                      8601 dates and times but doesn't accept "24:00" is broken.

                      Ed.
                    • piebaldconsult
                      You can t argue that it _should_ be in the spec because it _is_ in the spec. It s a non-sensical value (when dealing with an individual timepoint) and should
                      Message 10 of 10 , Dec 8, 2003
                      • 0 Attachment
                        You can't argue that it _should_ be in the spec because it _is_ in
                        the spec.

                        It's a non-sensical value (when dealing with an individual timepoint)
                        and should be removed from the spec. It does make sense as a duration
                        (i.e. "The party lasted T240000"), but that's it.

                        Here's the strongest argument against it with which I've yet come up:
                        If you send me "20031208T240000" and I put it in some non-text form
                        for processing and then back into text to send back to you, I'll be
                        sending "20031209T000000" -- which _is not_ what you sent me!
                        The computer will not format it back into "20031208T240000". There
                        should not be two ways to specify an individual timepoint (except
                        when different timezones and DST values are considered).

                        Here's another example:
                        You send me "20031208T230000Z-0100" and I convert it UTC, it
                        becomes "20031209T000000", _not_ "20031208T240000"! So even if you're
                        giving me a timespan that you think ends at "20031208T240000" it's
                        still "20031209T000000"!

                        If you call my program "broken" because I tell it not to
                        accept "T240000", then I'll call yours broken, because it produces
                        it -- a program would _not_ produce such a value, only a person would.

                        If there's a special "end" value for one type of value (day), then
                        they should *all* have end values.
                        Is the end of the year: "20031300" or "2003T240000" ?
                        Is the end of a month: "20031132" or "200311T240000" ?
                        Is "20031130T240000" the end of the day or the month?
                        What's the end of a minute or second?

                        The spec must be rule-based with no special exceptions, it must not
                        say times within an hour range from "0000" to "5959" -- oh, except
                        for hour "24", which can only be "0000".

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