Session Description Protocol - Time Formats and Repetitions

Time Formats and Repetitions

Absolute times are represented in Network Time Protocol (NTP) format (the number of seconds since 1900). If the stop time is 0 then the session is "unbounded." If the start time is also zero then the session is considered "permanent." Unbounded and permanent sessions are discouraged but not prohibited. Intervals can be represented with Network Time Protocol times or in typed time: a value and time units (days ('d'), hours ('h'), minutes ('m') and seconds ('s')) sequence.

Thus an hour meeting from 10am UTC on 1 August 2010, with a single repeat time a week later at the same time can be represented as:

t=1280656800 1281265200 r=604800 3600 0

Or using typed time:

t=1280656800 1281265200 r=7d 1h 0

When repeat times are specified, the start time of each repetition may need to be adjusted so that it will occur at the same local time in a specific timezone thoughout the period between the start time and the stop time (which are still specified in NTP format in an absolute UTC timezone.

Instead of specifying this timezone and having to support a database of timezones for knowing when and where daylight adjustments will be needed, the repeat times are assumed to be all defined within the same timezone, and SDP supports the indication of NTP absolute times when a daylight offset (expressed in seconds or using a type time) will need to be applied to the repeated start time or end time falling at or after each daylight adjustment. All these offsets are relative to the start time, they are not cumulative. NTP supports this with the z= field which indicates a series of pairs, whose first item is the NTP absolute time when a daylight adjustment will occur, and the second item indicates the offset to apply relative to the absolute times computed with the r= field.

For example, if a daylight adjustment will substract 1 hour on 31 October 2010 at 03am UTC (i.e. 60 days minus 7 hours after the start time on Sunday 1 August 2010 at 10am UTC), and this will be the only daylight adjustment to apply in the scheduled period which would occur between 1 August 2010 up to the 28 November 2010 at 10am UTC (the stop time of the repeated 1h session which is repeated each week at the same local time, which occurs 88 days later), this can be specified as:

t=1280656800 1290938400 r=7d 1h 0 z=1288494000 -1h

If the weekly 1-hour session was repeated every Sunday for full one year, i.e. from Sunday 1 August 2010 03am UTC to Sunday 26 June 2011 04am UTC (stop time of the last repeat, i.e. 360 days plus 1 hour later, or 31107600 seconds later), so that it would include the transition back to Summer time on Sunday 27 March 2011 at 02am (1 hour is added again to local time, so that the second daylight transition would occur 209 days after the first start time):

t=1280656800 1290938400 r=7d 1h 0 z=1288494000 -1h 1269655200 0

As SDP announcements for repeated sessions should not be made to cover very long periods exceeding a few years, the number of daylight adjustments to include in the z= parameter should remain small.

Note also that sessions may be repeated irregularly over a week but scheduled the same way for all weeks in the period, by adding more tuples in the r parameter. For example to schedule the same event also on Saturday (at the same time of the day) you would use :

t=1280656800 1290938400 r=7d 1h 0 6d z=1288494000 -1h 1269655200 0

The SDP protocol does not support repeating sessions monthly and yearly schedules with such simple repeat times, because they are irregularly spaced in time; instead, additional t/r tuples may be supplied for each month or year.