Subject: repeat times

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Jun 1995 21:21:11 +0200

It would probably help if we could list some typical applications for 
our discussion. The ones that I see:
a) radio programs (every 15 min, every hour, every day at the same time)
b) lectures (either once a week or at mostly regular times, with a few
  odd ones thrown in due to holidays, and such)
c) the rest

Most of the events that I can think of that have odd repeat times occur 
infrequently enough that explicit enumeration is sufficient (like the 
Hamming lectures or your typical college course.

As I had mentioned to Mark earlier, the Sun calendar manager offers a 
user interface and specification format which seems reasonable.

If at all possible, I'd like to avoid the DST issue, particularly since 
the beginning of DST is not uniform around the world. You slowly get 
yourself to the timezone file...

How about specifiying offsets in seconds, but also allowing 7d (that 
is, seven days, for the weekly stuff) and such, to avoid the DST issue. 
I somehow don't foresee the urgent need to specify a session that 
begins at 9:15 one day, 10:30 the next, 11:45 the day after, etc. For 
the byte counters, the notation is even a bit shorter...

Thus, two formats: second offset for the (a) case, days for the longer 
term things where seconds would break down due to DST.

r=<repeat count> <repeat interval> [...]

<repeat interval> := integer | integer d

The whole sequence repeats until repeat count is reached; that makes it 
easy to specify Monday and Tuesday of each week for a thirteen-lecture 
class as:
r=13 1d 6d

[A user interface for generating times may just allow some reasonable 
subset; for display, a calendar is probably best anyway.]

The duration is already specified by the difference between <starttime> 
and <stoptime> (Or did I misunderstand <stoptime>?). Or do we need to 
cater to programs of varying lengths at each time? 

Henning

---

From: Mark Handley <[email-masked]>
Date: Wed, 14 Jun 95 21:02:36 +0100

>user interface and specification format which seems reasonable.

Yes, it's a good example, though it's trying to solve a slightly
different problem - it's much more important in SDP that this is a TZ
independant format.  

>yourself to the timezone file...

I would too, but I doubt we can.  The format for the "z=" field I
specified makes it very easy for receivers to add the relevant offset
or not - they don't need to be smart.  It's much more difficult for
senders though.  As it's easy for receivers, I'm not concerned much
with adding it - it's clearly optional for senders.  

I should add that the "z=" field is not strictly necessary if we use
the "t=" and "r=" fields as I described them, as you could repeat your
"r" fields with a different "t" field for summer time.  This is pretty
foul though.

>the byte counters, the notation is even a bit shorter...

I quite like the 7d format for compactness

However, it doesn't solve the DST issue.  People change to/from DST at
different times and *dates* depending on where in the world you live
(plus not everyone changes at all). Thus for the 7d notation to solve
the problem you need to know the TZ of the person making the
announcement, your TZ, and whether both of them are on DST, or are
different, and then add an offset to the starttime if necesary.
Although the local data may be available, the remote data may not
always be, so I wanted to avoid this and make it easy on the receiver.

>easy to specify Monday and Tuesday of each week for a thirteen-lecture 

If you want to do two lectures a week at 9am Monday and 11 am tuesday
(like most of the courses at UCL!), your scheme above becomes:
r=13 93600 511200
this is probably at least as likely as them being at the same time, so
you may not gain as much from the "d" notation as maybe you think.

>cater to programs of varying lengths at each time? 

You misunderstood <stoptime>.

If you have a repeat sequence, then you either need to specify the
number of repeats or the absolute endtime.  I took the view that
absolute endtime was (marginally) easier, as it allowed you to put
several different duration events under the same "t=" field.  For
example, your session might be active for 1 hour on mondays and 2
hours on tuesdays repeating every week until <stoptime>.

It also (marginally) simplifies the code for timing out sessions.

Both your scheme and mine are funtionally equivalent though.  I don't
have a strong opinion either way, except I have code for mine, which
isn't really a good reason :-)

Mark (wishing he never got involved with repeat times :-)