Smalltalk - Calendar Math

Author

Calendar Math

Thomas Gagné

2004-04-02, 9:40 am

I've always been curious about calendar programs. Mostly re: how they
stored the data. Obviously, an event that repeats forever isn't stored
an infinite number of times. So when it came time to display a
calendar, how did they know what event fell on each day?

When I ran across a bunch of e-articles about iCal, xCAL, CAP, and a few
other things I saw an example of how the data was stored, but I can't
find an example of the code to use it.

One way of doing it would be to create a list of all the events, and for
each day your interested in (say the days this w

) ask each of the
events if they'll be occuring on that day:

aCalendarDay := CalendarDay newFor: Date today.

aListOfEvents do: [ :event |
(event occursOn: aCalendarDay) ifTrue: [
aCalendarDay addEvent: event
].
].

To display a calendar of 30 days this loop would be repeated 30 times.
Ultimately aCalendarDay is displayed to the user somehow. Another
function would be to bump to event lists together to find available time
between them--everybody's used that function in some group ware. I just
don't seem able to find the functions on the web.

I'm sure someone else has done this. What better ways of doing it are
there?

I'm thinking about a class library for working with the new iCal format,
aggregating calendars, better storage, versioning, etc. Not to mention
a nice calendar utility accessible to Smalltalk for all those times we
need calendars in our application to keep track of payroll dates, check
runs, or anything else.

--
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Lex Spoon

2004-04-02, 4:35 pm

Thomas Gagné <tgagne@wide-open-west.com> writes:
> One way of doing it would be to create a list of all the events, and
> for each day your interested in (say the days this w

) ask each of
> the events if they'll be occuring on that day:
>
> aCalendarDay := CalendarDay newFor: Date today.
>
> aListOfEvents do: [ :event |
> (event occursOn: aCalendarDay) ifTrue: [
> aCalendarDay addEvent: event
> ].
> ].
>
> To display a calendar of 30 days this loop would be repeated 30 times.

I would be tempted to try this simple approach. If you have a hefty
1000 events in the calender, then that's 30,000 checks to display one
month. This might be pretty cheap for a computer that does
1,000,000,000 instructions per second, depending on how complicated
the "do you happen on ___" check is.

A faster alternative is to flip it around and iterate the other way;
loop through the events asking each one for the times it occurs within
some range of days. Then display each event at each time it reported.

Only if both of these alternatives is too slow would I play around
with something more complicated. I'd probably try adding some
indexes, specifically "what events happen on monday/tuesday/etc." and
"what events happen on the 1st/2nd/3rd/etc. of the month". Require
that each event be registered one way or the other, or that it is
added to a separate "irregular" index. Note, though, that indexes are
going to add extra complexity to the whole module that maintains the
event collection.

By the way, it's crucial, for this consideration, that you obtain some
realistic calender data to play with as you try the different
approaches. Otherwise you won't know what works and what doesn't.

> Ultimately aCalendarDay is displayed to the user somehow. Another
> function would be to bump to event lists together to find available
> time between them--everybody's used that function in some group ware.

I'd be tempted to try the same kind of reasoning used in option #2
above. Ask every event for what times they use on some range of
days--possibly a single day--and then see what times are left over.

> I'm thinking about a class library for working with the new iCal
> format, aggregating calendars, better storage, versioning, etc. Not
> to mention a nice calendar utility accessible to Smalltalk for all
> those times we need calendars in our application to keep track of
> payroll dates, check runs, or anything else.

There is a book called "Calendrial calculations" that you should look
into.

Also, Squeak does include some time and date classes, particularly in
the Chronology package. I am sure there are other such packages
floating around; the point is that you may want to throw weight behind
an existing project instead of starting from scratch.

-Lex

Jeff Brooks

2004-04-03, 9:32 am

Personally i would speed it up in the following ways:

I would have a dictionary that is keyed by date that contains an
OrderedCollection of the events that happen on that day.

I would also have a collection of reacurring events.

I would wrap both of these in a Calendar class that has a
getEventsForDate: method which looks something like this:

Calendar>>getEventsForDate: aDate
| events |
events := OrderCollection new.
events addAll: (dateEvents at: aDate ifAbsent: [#()]).

reacurringEvents do: [ :event |
(event occursOn: aDate) ifTrue: [
events add: event.
].
].

^ events.

The idea is there should be a lot of events that happen on specific days
but less reacurring events. By using a dictionary the number of events
that need to be checked to get a collection of events that happen on a
specific day is greatly reduced.

Jeff Brooks

Thomas Gagné wrote:
> I've always been curious about calendar programs. Mostly re: how they
> stored the data. Obviously, an event that repeats forever isn't stored
> an infinite number of times. So when it came time to display a
> calendar, how did they know what event fell on each day?
>
> When I ran across a bunch of e-articles about iCal, xCAL, CAP, and a few
> other things I saw an example of how the data was stored, but I can't
> find an example of the code to use it.
>
> One way of doing it would be to create a list of all the events, and for
> each day your interested in (say the days this w

) ask each of the
> events if they'll be occuring on that day:
>
> aCalendarDay := CalendarDay newFor: Date today.
>
> aListOfEvents do: [ :event |
> (event occursOn: aCalendarDay) ifTrue: [
> aCalendarDay addEvent: event
> ].
> ].
>
> To display a calendar of 30 days this loop would be repeated 30 times.
> Ultimately aCalendarDay is displayed to the user somehow. Another
> function would be to bump to event lists together to find available time
> between them--everybody's used that function in some group ware. I just
> don't seem able to find the functions on the web.
> I'm sure someone else has done this. What better ways of doing it are
> there?
>
> I'm thinking about a class library for working with the new iCal format,
> aggregating calendars, better storage, versioning, etc. Not to mention
> a nice calendar utility accessible to Smalltalk for all those times we
> need calendars in our application to keep track of payroll dates, check
> runs, or anything else.
>

Thomas Gagné

2004-04-03, 5:32 pm

Great comments. Thanks Lex and Jeff.

Lex Spoon wrote:

>Thomas Gagné <tgagne@wide-open-west.com> writes:
>
>
>
>By the way, it's crucial, for this consideration, that you obtain some
>realistic calender data to play with as you try the different
>approaches. Otherwise you won't know what works and what doesn't.
>
>
>
There's 1700+ calendars available in the public domain in .ics format.
That should provide plenty of examples.

>
>There is a book called "Calendrial calculations" that you should look
>into.
>
>
I'm off to Amazon to find it.

>Also, Squeak does include some time and date classes, particularly in
>the Chronology package. I am sure there are other such packages
>floating around; the point is that you may want to throw weight behind
>an existing project instead of starting from scratch.
>
>
According to the doc I found <http://minnow.cc.gatech.edu/squeak/1871>
many of the classes are implementations of the ANSI standard classes
<http://minnow.cc.gatech.edu/squeak/...1_9-indexed.pdf>.
But none of them seemed particularly addressed to the maintenance of
calendars--but I'll read it several more times before I'm done.

Of course, I'll need names for the classes--and that's always fun.
Since the point is to manipulate and express calendars I'll need some
kind of Date class that contains events and perhaps even tasks. I
wonder if some classes already exist in another language that might
present a starting point. Know of any?

Some things I'd like the package to do:

1. read .ics files
2. write .ics files
3. read & write xCAL (even though it seems to have lost steam)
4. implement CAP (calendar access protocol)
5. ask when the next occurrence of an event is after a give date
6. ask when the last occurrence of an event was before a given date
7. get a list of events between a date range
8. calculate a durations between when something was supposed to occur
when it actually did.

I think that's a good start. If anyone can think of something else I'm
all ears.

--
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Terry Raymond

2004-04-04, 10:34 am

Thomas Gagné <tgagne@wide-open-west.com> wrote in
news:RIudnXRIBKbctvLdRVn-sA@wideopenwest.com:

> Of course, I'll need names for the classes--and that's always fun.
> Since the point is to manipulate and express calendars I'll need some
> kind of Date class that contains events and perhaps even tasks. I
> wonder if some classes already exist in another language that might
> present a starting point. Know of any?
>
> Some things I'd like the package to do:
>
> 1. read .ics files
> 2. write .ics files
> 3. read & write xCAL (even though it seems to have lost steam)
> 4. implement CAP (calendar access protocol)
> 5. ask when the next occurrence of an event is after a give date
> 6. ask when the last occurrence of an event was before a given date
> 7. get a list of events between a date range
> 8. calculate a durations between when something was supposed to
> occur
> when it actually did.

Instead of working with a calendar why not work with
the list of events? Each event would have a description
of when it occurs. The list could be sorted in order
of occurrence.

If you have repeating events you could ask the events to
provide the next event time after/before a date and so on.

--
Terry
========================================
===================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk *Breakpoints* and *Watchpoints* for
80 Lazywood Ln. VW and ENVY/Developer
Tiverton, RI 02878
(401) 624-4517 traymond at craftedsmalltalk nospam dot com
<http://www.craftedsmalltalk.com>
========================================
===================

Thomas Gagné

2004-04-05, 9:37 am

Terry Raymond wrote:

> <snip>
>
>
>Instead of working with a calendar why not work with
>the list of events? Each event would have a description
>of when it occurs. The list could be sorted in order
>of occurrence.
>
>If you have repeating events you could ask the events to
>provide the next event time after/before a date and so on.
>
>
>
I like that idea. EventList? I don't want it to sound like it belongs
to a GUI or IO driver. Perhaps that's what a Calendar is, a List of
Events? Perhaps Calendar and CalendarEvent...

--
..tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Sponsored Links