## The challenge

Expand Messages
• Time Event Algebraic Notation The ISO-8601 duration “PnYnMndTnHnMnS” is a brilliant start to time event algebra. The challenge, be the first to: ·
Message 1 of 9 , Jun 21, 2007

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=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.

See what's free at AOL.com.
• Many of those characters didn t come across properly. But it sure seems an uphill battle, good luck.
Message 2 of 9 , Jun 21, 2007
Many of those characters didn't come across properly. But it sure seems
an uphill battle, good luck.
• I had the same problem until I switched to Unicode encoding. However, one of the points of ISO8601 is that it only uses characters which are part of a basic
Message 3 of 9 , Jun 21, 2007
I had the same problem until I switched to Unicode encoding. However,
one of the points of ISO8601 is that it only uses characters which are
part of a basic ASCII subset, so why is this necessary?

I'm still pretty unclear on what we are being challenged to do.

--- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
wrote:
>
> Many of those characters didn't come across properly. But it sure
seems
> an uphill battle, good luck.
>
• ... Just trying to understand is a challenge.
Message 4 of 9 , Jun 21, 2007
> I'm still pretty unclear on what we are being challenged to do.

Just trying to understand is a challenge.
• 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 5 of 9 , Jun 22, 2007

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=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.

• 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 6 of 9 , Jun 22, 2007
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.
• 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 7 of 9 , Jun 22, 2007
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.
• 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 8 of 9 , Jun 24, 2007
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.
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.
• 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 9 of 9 , Jul 6, 2007

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.
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.