Subject: [MMUSIC] How to use SDP 'z=' field?

From: Bryan Thale <[email-masked]>
Date: Sat, 04 May 2002 16:04:03 -0500

Hi,

I'm having some difficulty figuring out the use of SDP's time zone
adjustment 'z=' field.  Is this field actually used in practice?
Couldn't the same function be provided by simply using two 't=' fields
to define one schedule for standard time and one for daylight savings
time?

The problem I'm having with understanding the 'z=' field is how to
encode the necessary adjustments when there are multiple repetition
schedules.  For example, suppose I have the following schedule where a
class is offered at 10AM on Monday, Wednesday, and Friday for both the
fall and spring semesters, but is also offered on Tuesdays and Thursdays
in the spring.  Ignoring holidays and semester breaks, this might be
specified as:

t=<26-AUG-01 10AM> <8-JUN-02>
r=7d 1h <monday> <wednesday> <friday>
t=<20-JAN-02 2PM> <8-JUN-02>
r=7d 2h <tuesday> <thursday>

The first repetion schedule requires two time zone adjustments:

z=<28-OCT-01 2AM> 1h <7-APR-02 2AM> 0

The second schedule requires one adjustment

z=<7-APR-02 2AM> -1h

I might have the signs wrong on the adjustments, but the important point
is that on April 7th one schedule needs to revert to its base time to
undo the October 28 adjustment while the second schedule needs to
specify a one hour adjustment to its base time.  How do I do that with a
single 'z=' field?

If the schedule is encoded to account for semester breaks and thus no
longer contains overlapping periods:

t=<26-AUG-01 10AM> <22-DEC-01>
r=7d 1h <monday> <wednesday> <friday>
t=<20-JAN-02 2PM> <8-JUN-02>
r=7d 1h <monday> <wednesday> <friday>
r=7d 2h <tuesday> <thursday>

Would the 'z=' field still be:

z=<28-OCT-01 2AM> 1h <7-APR-02 2AM> 0

or would it now be:

z=<28-OCT-01 2AM> 1h <7-APR-02 2AM> -1h

Again, I might have the signs reversed, but the point is what happens on
April 7th?  Does the 'z=' field say "revert to base time" or does it
define a new one hour adjustment?  Or is there actually one 'z=' field
per 't=' field rather than one per session description?

Thanks,
Bryan.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Thu, 09 May 2002 13:44:21 +0100

Bryan,

Good questions, of which I'm not entirely sure of the correct answer. You
could avoid the issue by defining all the sessions as if daylight savings
time were not in force, and including an initial 'z=' offset before the
start time, something like:

z=<8-APR-01 2AM> -1h <28-OCT-01 2AM> 0h <7-APR-02 2AM> -1h

but that doesn't seem clean. Alternatively, we could make 'z=' part of the
time description, so there was one per 't=' line.

I'd be interested in other opinions though.

Colin

---

From: Bryan Thale <[email-masked]>
Date: Thu, 09 May 2002 11:09:21 -0500

Colin,

Given this statement from the definition of the 'z=' field:

> To simplify this task for
> receivers, we allow the sender to specify the NTP time that a time
> zone adjustment happens and the offset from the time when the
> session was first scheduled.
>

it seems that the intent of the 'z=' field is to be relative to the 't='
field.  That would argue for modifying the grammar to allow an optional 'z='
field per 't=' field rather than one per session description.

On the other hand, is 'z=' really necessary?  A simple mandate that 't='
fields not span DST transitions would avoid the whole complicated mess all
together but might be a more intrusive alteration of the protocol if the 'z='
field is actually in use by someone.  This might be more applicable to the
SDPng work since they have no backward compatibility baggage to accommodate.

Bryan.

---

From: Mark Handley <[email-masked]>
Date: Thu, 09 May 2002 10:15:46 -0700

>>per 't=' field rather than one per session description?

I don't see what the problem is.

The specified start time is <26_AUG-01 10AM>.  All z field entry
offsets are relative to that the timebase that is existence at that
time, irrespective of any additional t fields.

The example in RFC 2327 says:

     An example might be:

                        z=2882844526 -1h 2898848070 0

     This specifies that at time 2882844526 the time base by which the
     session's repeat times are calculated is shifted back by 1 hour,
     and that at time 2898848070 the session's original time base is
     restored. Adjustments are always relative to the specified start
     time - they are not cumulative.

So in your example above, you'd put:

As for the sign of the offset:

Imagine you're in Britain, and before 28-Oct your timezone is on BST
(UTC+1), and after 28-Oct it is on GMT (UTC+0).

You want the session to be at 10am.  Then the session would be at 
9am UTC == 10am UTC+1 before 28-Oct, and it would be at 10am UTC after
28-Oct.  Thus the session stays at 10am localtime.

If the session occurs at 9am UTC before 28-Oct-01, the z field above
says that it occurs at 10am UTC after 28-Oct-01, hence the sign is
positive in this case.

Cheers,
	Mark

---

From: Bryan Thale <[email-masked]>
Date: Thu, 09 May 2002 14:46:14 -0500

Hi Mark,

Hmm, OK, so what you are saying is that the function to calculate the 
offset to be applied to the start time of  a repetition is:

offset( repetition start time ) = zoffset( repetition start time ) - 
zoffset( current 't=' start time )

where the 'zoffset' function returns the offset value from the 'z=' 
field with the greatest  timestamp less than or equal to the argument 
 So, with this schedule:

For the first repetition schedule I would have:
offset(28-AUG-01 10AM)=zoffset(28-AUG-01 10AM)-zoffset(26-AUG-01 10AM)=0-0=0
offset(28-JAN-02 10AM)=zoffset(28-JAN-02 10AM)-zoffset(26-AUG-01 10AM)=1-0=1
offset(06-MAY-02 10AM)=zoffset(06-MAY-02 10AM)-zoffset(26-AUG-01 10AM)=0-0=0

While for the second repetition schedule I would have:
offset(29-JAN-02 2PM)=zoffset(29-JAN-02 2PM)-zoffset(20-JAN-02 2PM)=1-1=0
offset(07-MAY-02 2PM)=zoffset(07-MAY-02 2PM)-zoffset(20-JAN-02 2PM)=0-1=-1

Is that correct?

Bryan.

---

From: Mark Handley <[email-masked]>
Date: Thu, 09 May 2002 14:28:46 -0700

>offset(07-MAY-02 2PM)=zoffset(07-MAY-02 2PM)-zoffset(20-JAN-02 2PM)=0-1=-1

I'm not sure I understand your terminology, but I don't think that's
correct.

Given the above SDP, the offsets are:

Any repeat time in range <26-AUG-01 10AM> to <28-OCT-01 2AM>: 0
Any repeat time in range <28-OCT-01 2AM> to <7-APR-02 2AM>: 1h
Any repeat time in range <7-APR-02 2AM> to <8-JUN-02>: 0h

These offsets apply, irrespective of which t line the repeat time
comes from.

 - Mark

---

From: Bryan Thale <[email-masked]>
Date: Thu, 09 May 2002 19:11:04 -0500

Ok, then here is the problem I have...

For the second repetition interval, the one defined to begin at 
20-JAN-02 2PM (Standard Time) and ends at midnight 8-JUN-02 (DST), the 
offset that needs to be applied  *after* 7-APR-02 1:59:59.999AM 
(Standard Time)  is -1h, not the 0 specified in the 'z=' field.  The 
offsets specified in the 'z=' field are only valid for the first 
repetition schedule that runs from 26-AUG-01 10AM (DST) through midnight 
8-JUN-02 (DST) since the offsets are relative to DST and not Standard Time.

Bryan.

---

From: Mark Handley <[email-masked]>
Date: Thu, 09 May 2002 18:53:05 -0700

>8-JUN-02 (DST) since the offsets are relative to DST and not Standard Time.

No - the offsets for the second sequence before 7-APR-02 are +1h.  The
offsets after that are 0h.

 - Mark

---

From: Colin Perkins <[email-masked]>
Date: Fri, 10 May 2002 11:20:41 +0100

Okay, so the base times of all intervals need to be specified according to
the time zone active when the first interval starts?

That is, the second 't=' line would be offset be one hour, and this offset
will be corrected by the 'z=' offset to bring it to the correct local time.
Right?

Colin

---

From: Bryan Thale <[email-masked]>
Date: Fri, 10 May 2002 10:19:31 -0500

Gads, I sure hope not.  There is nothing in the RFC or the drafts that even
hints at that behavior.  Why would you tie the 't=' fields together like that?
There is no possible scenario of timezone and DST adjustments that would ever
render the start and stop times of the 't=' fields ambiguous in any way so
there is no need to mess around with those timestamps.

The 'z=' field should only come into play, if at all, while processing the
calculated timestamps of the 'r=' field.  That is because twice a year there
are 2 days that don't contain exactly 24 hours according to the local wall
clock so any timestamps that are *calculated* from a base timestamp need to be
adjusted when they cross those boundaries.  10AM on 6-APR-02 and 10AM on
7-APR-02 are less than 24 hours apart so you can't calculate the timestamp for
10AM 7-APR-02 simply by adding 24 hours to the timestamp for 10AM 6-APR-02.
But that doesn't change the start and stop times for the session's 't='
intervals.

Personally, I'm leaning toward breaking my repetition schedules into multiple
't=' fields at DST transitions so that an individual 't=' field never spans
such a boundary and never requires a 'z=' field.  This has the added benefit
that a repeat schedule can never result in a non-existent time.  The current
definition of the interplay between the 't=', 'r=', and 'z=' fields allows the
generation of a timestamp such as 7-APR-02 2:30 AM Standard Time which doesn't
exist.  Unfortunately, while that works great for schedules that I generate, it
doesn't help with schedules that I receive from other sources that might
contain 'z=' fields and that I have to interpret.

Bryan.

---

From: Mark Handley <[email-masked]>
Date: Fri, 10 May 2002 09:37:18 -0700

>will be corrected by the 'z=' offset to bring it to the correct local time.

Yes, that's exactly right.  The z field offsets apply to all t lines.

 - Mark