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

RE: [ISO8601] The challenge

Expand Messages
  • tex
    Herman, Thanks for this. I think the answer is to become more Babbage then Newton. Whereas calculus is effective for some calculations, the digital, mechanical
    Message 1 of 9 , Jun 22 2:37 AM
    • 0 Attachment

      Herman,

       

      Thanks for this. I think the answer is to become more Babbage then Newton . Whereas calculus is effective for some calculations, the digital, mechanical counting mechanisms of the census are much more suitable to event math.

      It’s a little bit like doing Fourier transforms to use frequencies where they are more efficient and then converting back to spatial dimensions for the end results.

       

      Personally, I think it is a mistake to use names like addMonth, AddYear, because the number of seconds you need to add depends on the start value and the number of months or years etc. to be added (or subtracted if negative).

       

      Instead I would think of it as NextMonthlyAnniversary, NextAnniversary, NextWeeklyAnniversary, etc. (“Anniversary” is generalized and not used in the sense of an annual occurrence.)

      So Next month, adds one to the month field which can represent a variable number of seconds of actual time units, since it can be a 28, 29, 30, or 31 day month, it might include a leap second, a change to/from daylight savings, etc.

       

      If the month value exceeds the maximum (12) then of course it wraps to 1 and the year must be upped.

       

      Once you generate the intended anniversary you can convert it to the number of seconds since the time epoch and calculate the actual number of seconds greater than the start event.

       

      Maybe a better analogy than the fourier transform is to consider flying across the surface of the spherical earth.

      You can travel 1 mile south and 1 mile west and 1 mile north, and depending whether your starting point is the north pole or not, you can end up at the same or a different point from the origin.

       

      tex

       


      Time Event Algebraic Notation

       

      The ISO-8601 duration “PnYnMndTnHnMnS” is a brilliant start to time event algebra.

       

      The challenge, be the first to:

      ·          Develop formulas for all the holidays.

      ·          Develop a formula to convert calendar date to ordinal date and back.

      ·          Devlope a formual to convert calendar ate to week date and back.

      ·          Develop improvements to event algebra formulas.

       

      I will program the parsing of the formula to prove them correct!

      Use the following expanded formuals as explained in this article and invent other symbols:

      ±P±nY±nM±nDT±nH±nM±nS±nF            date/time arithmetic

      ±P±nY±nW±nDT±nH±nM±nS±nF     week of year arithmetic

      =P=nY=nM=nDT= nH=nM=nS= nF     set calendar date/time

      =P=nY=nW=nDT= nH=nM=nS= nF set week of years date/time

      Maybe you might become a Babbage or Newton , but probable something less.

      The problem, scheduling software, appointment software, other software, cell phone, PDAs and even watches need a universal method of expressing past and future events.  Past dates require retentions times after the date for update or delete, and future dates require reminder times before the date for notification.   A Web based program should be able to auto-synchronize a server master list with client computer software, the cell phone and a computer or cell phone should be able to synchronize a watch.  The modern electronic age needs a universal standard language to provide descriptions of events (holidays, birthdays, meeting …etc) and that provide for retention and notification in a systematic way.        

    • hjwoudenberg@aol.com
      In a message dated 6/22/2007 4:39:12 A.M. Central Daylight Time, tex@yahoo-inc.com writes: Personally, I think it is a mistake to use names like addMonth,
      Message 2 of 9 , Jun 22 5:51 PM
      • 0 Attachment
        In a message dated 6/22/2007 4:39:12 A.M. Central Daylight Time, tex@... writes:

        Personally, I think it is a mistake to use names like addMonth, AddYear, because the number of seconds you need to add depends on the start value and the number of months or years etc. to be added (or subtracted if negative).

         
        It is bad and unnecessary with the ISO-8601 duration. 
         
        I meant this as sarcasm and some element of ignorance:
         
        "However, for the last 20 years the solutions of choice has been 2 or 3 dozen individual functions.  Attempts to use a cool name for a deficient function has not made them useful."
         
        hjw




        See what's free at AOL.com.
      • hjwoudenberg@aol.com
        In a message dated 6/22/2007 4:39:12 A.M. Central Daylight Time, tex@yahoo-inc.com writes: Instead I would think of it as NextMonthlyAnniversInstead I would
        Message 3 of 9 , Jun 22 7:04 PM
        • 0 Attachment
          In a message dated 6/22/2007 4:39:12 A.M. Central Daylight Time, tex@... writes:

          Instead I would think of it as NextMonthlyAnnivers ary, NextAnniversary, NextWeeklyAnniversa ry, etc. (“Anniversary” is generalized and not used in the sense of an annual occurrence.)

          i se the need as being able to transfer either a duration or and event from different software, or cell phone, PDA or watch.
           
          I choose durations
              P
              +P
              -P
           
          I choose for event
              =P
              @P
           
          Another choose would be to replace P with E for event
          How many think this is a better?
           
          The formula must identify if a duration or a event, else when transferring formulas from one software to another or one device to another the receiving software or device doesn't know what it is.
           
          hjw
           
           
              




          See what's free at AOL.com.
        • datefreak
          It s foolish to think that REAL improvement ever might be possible as long as differences and/or irregularities in our (or any) date/time tracking systems will
          Message 4 of 9 , Jun 24 2:43 AM
          • 0 Attachment
            It's foolish to think that REAL improvement ever might be possible as
            long as differences and/or irregularities in our (or any) date/time
            tracking systems will exist. Simply think about different calendars
            (Gregorian, Hebrew, Chinese etc.), different time zones, Easter date,
            different numbers of days in months in general and leap days/seconds
            in particular, etc.
            So why bother about improvement of existing formulas? Already using
            P, what's available now does the job, doesn't it? Any changes would
            be only cosmetic.

            But you made a very big point about synchronization of all hardware
            systems that use time. Problem is that the long known and for sure
            best solution probably will not be implemented in our lifetime! Do
            you realize how long it took to implement the ISO 8601 notation?
            (Alexander Graham Bell used that already in the 1880's! And still,
            what notation do you read now in the header of this message?)

            It would be nice if every watch, computer, cell phone, electric oven,
            car or whatever hardware, internally as well as for interchange only
            would use a Universal Atomic Second Number (kind of UTC measured in
            seconds) being transmitted continuously, and would give it's user the
            opportunity to make it convert that to any calendar of his own choice
            and show that on the display, using GPS to calculate correct Z .....

            THAT would really ease things up and facilitate simple formulas!
            And would completely skip your challenge for new Babbages or Newtons!

            Regards,
            Jan


            --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
            >
            > The challenge, be the first to:
            > · Develop formulas for all the holidays.
            > · Develop a formula to convert calendar date to ordinal
            date and
            > back.
            > · Devlope a formual to convert calendar ate to week date
            and back.
            > · Develop improvements to event algebra formulas.
          • tex
            Actually, it is foolish to think we can’t improve. The fact that there are differences and irregularities just makes the job harder, not necessarily
            Message 5 of 9 , Jul 6, 2007
            • 0 Attachment

              Actually, it is foolish to think we can’t improve.

              The fact that there are differences and irregularities just makes the job harder, not necessarily impossible.

              And the current syntax (P) does not do the entire job that is needed.

               

              Yes, it does take a long time to change, and sometimes it doesn’t take at all (consider the metric system in the US ). On the other hand, some impossible tasks, such as the cataloging and categorization of all characters used in writing systems throughout the world, does make very good on its mission and is accepted, albeit over a 15 year period (Unicode).

               

              I am still hopeful that we will all use stardates (from Star Trek) some day.

              ;-)

               

              tex

               

               


              From: ISO8601@yahoogroups.com [mailto: ISO8601@yahoogroups.com ] On Behalf Of datefreak
              Sent: Sunday, June 24, 2007 2:43 AM
              To: ISO8601@yahoogroups.com
              Subject: [ISO8601] Re: The challenge

               

              It's foolish to think that REAL improvement ever might be possible as
              long as differences and/or irregularities in our (or any) date/time
              tracking systems will exist. Simply think about different calendars
              (Gregorian, Hebrew, Chinese etc.), different time zones, Easter date,
              different numbers of days in months in general and leap days/seconds
              in particular, etc.
              So why bother about improvement of existing formulas? Already using
              P, what's available now does the job, doesn't it? Any changes would
              be only cosmetic.

              But you made a very big point about synchronization of all hardware
              systems that use time. Problem is that the long known and for sure
              best solution probably will not be implemented in our lifetime! Do
              you realize how long it took to implement the ISO 8601 notation?
              (Alexander Graham Bell used that already in the 1880's! And still,
              what notation do you read now in the header of this message?)

              It would be nice if every watch, computer, cell phone, electric oven,
              car or whatever hardware, internally as well as for interchange only
              would use a Universal Atomic Second Number (kind of UTC measured in
              seconds) being transmitted continuously, and would give it's user the
              opportunity to make it convert that to any calendar of his own choice
              and show that on the display, using GPS to calculate correct Z .....

              THAT would really ease things up and facilitate simple formulas!
              And would completely skip your challenge for new Babbages or Newtons !

              Regards,
              Jan

              --- In ISO8601@yahoogroups .com, hjwoudenberg@ ... wrote:

              >
              > The challenge, be the first to:
              > · Develop formulas for all the holidays.
              > · Develop a formula to convert calendar date to ordinal
              date and
              > back.
              > · Devlope a formual to convert calendar ate to week date
              and back.
              > · Develop improvements to event algebra formulas.

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