Subject: [Ietf-calsify] new section in recurrence rule definition (exact duration versus nominal duration)

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Thu Apr 5 12:23:37 2007

Hello,

I'm having a hard time trying to understand the following new section in the recurrence rule definition at: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.5.3

<<
If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs.  The
      duration of a specific recurrence may be modified in an exception
      component or simply by using an "RDATE" property of PERIOD value
      type.

While browsing the archives, I have found the following example (from http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000482.html) which summarized quite well my layman undestanding of the difference between using DTSTART+DTEND versus DTSTART+DURATION in a recurring event.

<<
Case a:

  A shift of work: 10pm - 6am. This is when I work, those times being in
  my local timezone. Most days my shift will be 8 hours long, on
  occaisonal days it will be 7, and on others it will 9.
  
Maybe my company will pay me for the 8 hours on days I only work 7,
thats an accounting issue, not a scheduling issue. Either way, they
don't have two chairs at the security desk that I work at, there is no
point me standing there looking over the other guards shoulder. Our
shifts do not overlap, on any day.

This is an example of when DTEND would be used. DTSTART is when I start
work, DTEND is when I end work, very simple, always right.

Case b:

  My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get
  more or less.

This is an example of when DURATION would be used.

What I thought was a clear example is in opposition with the new calsify section, especially with the DTEND part:

"If the duration of the recurring component is specified with the "DTEND" or "DUE" property, then the same exact duration will apply to all the members of the generated recurrence set."

Has the meaning of a DTSTART/DTEND recurring event changed ? Or is the example above plain wrong ? Or maybe I don't understand the meaning of "exact duration" ? 

About the DURATION part, I think it would really help to state (e.g. in the duration definition) what we mean by nominal duration, for example (taking almost verbatim from the ISO 8601 definition):

<<
Duration can be expressed by a combination of components with accurate duration (hour, minute and second)
and components with nominal duration (week and day).

The duration of a calendar week or a calendar day depends on its position
in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar
years, calendar months, calendar weeks or calendar days used are known.

Finally, in most cases, a DURATION will contain only accurate durations and hence, all instances will have the same exact duration. A few extra words could clarify that I think. Something like:

      If the
      duration of the recurring component is specified with the
      "DURATION" property, then **that same duration** will apply to
      all the members of the generated recurrence set. **If this duration contains values with nominal duration**, the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs...

Arnaud Q

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Apr 5 19:19:00 2007

Proposed language changes to solve some of the vagueness. Feel free to
correct any errors, or improve upon this text:

3.8.2.2 (DTEND)  Add a paragraph to the description which reads:

	DTEND can be used with DTSTART to calculate the duration of an
component. The duration of a component is the difference between the DTEND
time and the DTSTART time. If the interval from DTSTART to DTEND crosses a
timezone shift, and VALUE parameter is DATE-TIME for DTSTART, then the
calculated duration must account for the time which is gained or lost during
the shift.

3.8.2.5 (DURATION) add a paragraph to the description which reads:
	DURATION can be used to calculate the ending date and time of a
component, by adding DURATION to DTSTART. If the resulting calculation
results in an endpoint which is across a timezone shift from DTSTART, then
the endpoint should be adjusted to account for the time which is gained or
lost during the shift so that the actual duration is equal to that
requested.

3.8.5.3 (RECURRENCE RULE)
	If the duration of the recurring component is specified with the
"DTEND" or "DUE" property, and the VALUE parameter is DATE-TIME, then the
duration applied to all members of the recurrence set should be calculated
as specified for the "DTEND" component of the first member of the recurrence
set, including adjusting the duration because of the timezone shift. If the
duration is specified with the "DURATION" property, then the duration should
be that specified for the "DURATION" property, and any calculations to
determine the end date and time of the member must make adjustments for any
timezone shift. For example, expansion of recurrence rules with a DURATION
property of one hour should always result in individual members of the set
with a duration of one hour, and should not shrink to zero hours or expand
to two hours because of timezone changes.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Arnaud Quillaud
Sent: Thursday, April 05, 2007 3:23 PM
To: [email-masked]
Subject: [Ietf-calsify] new section in recurrence rule definition (exact
duration versus nominal duration)

Hello,

I'm having a hard time trying to understand the following new section in the
recurrence rule definition at:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.5.3

<<

While browsing the archives, I have found the following example (from
http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000482.html
) which summarized quite well my layman undestanding of the difference
between using DTSTART+DTEND versus DTSTART+DURATION in a recurring event.

<<
Case a:

Maybe my company will pay me for the 8 hours on days I only work 7, thats an
accounting issue, not a scheduling issue. Either way, they don't have two
chairs at the security desk that I work at, there is no point me standing
there looking over the other guards shoulder. Our shifts do not overlap, on
any day.

Case b:

What I thought was a clear example is in opposition with the new calsify
section, especially with the DTEND part:

"If the duration of the recurring component is specified with the "DTEND" or
"DUE" property, then the same exact duration will apply to all the members
of the generated recurrence set."

Has the meaning of a DTSTART/DTEND recurring event changed ? Or is the
example above plain wrong ? Or maybe I don't understand the meaning of
"exact duration" ? 

About the DURATION part, I think it would really help to state (e.g. in the
duration definition) what we mean by nominal duration, for example (taking
almost verbatim from the ISO 8601 definition):

<<
Duration can be expressed by a combination of components with accurate
duration (hour, minute and second) and components with nominal duration
(week and day).

The duration of a calendar week or a calendar day depends on its position in
the calendar. Therefore, the exact duration of a nominal duration can only
be evaluated if the duration of the calendar years, calendar months,
calendar weeks or calendar days used are known.

Finally, in most cases, a DURATION will contain only accurate durations and
hence, all instances will have the same exact duration. A few extra words
could clarify that I think. Something like:

      If the
      duration of the recurring component is specified with the
      "DURATION" property, then **that same duration** will apply to
      all the members of the generated recurrence set. **If this duration
contains values with nominal duration**, the exact
      duration of each recurrence instance will depend on its specific
      start time.  For example, recurrence instances of a nominal
      duration of one day will have an exact duration of more or less
      than 24 hours on a day where a time zone shift occurs...

Arnaud Q

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Tue Apr 10 06:49:01 2007

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Tim Hare
> Envoy? : vendredi 6 avril 2007 04:18
> ? : [email-masked]
> Objet : RE: [Ietf-calsify] new section in recurrence rule 
> definition (exact duration versus nominal duration)
> 
> 
>  
> Proposed language changes to solve some of the vagueness. 
> Feel free to correct any errors, or improve upon this text:
> 
> 	DTEND can be used with DTSTART to calculate the 
> duration of an component. The duration of a component is the 
> difference between the DTEND time and the DTSTART time. If 
> the interval from DTSTART to DTEND crosses a timezone shift, 
> and VALUE parameter is DATE-TIME for DTSTART, then the 
> calculated duration must account for the time which is gained 
> or lost during the shift.

Sounds good. Same could be said about DTSTART + DUE properties although VTODO with a DUE but no DTSTART are allowed.

> 	DURATION can be used to calculate the ending date and 
> time of a component, by adding DURATION to DTSTART. If the 
> resulting calculation results in an endpoint which is across 
> a timezone shift from DTSTART, then the endpoint should be 
> adjusted to account for the time which is gained or lost 
> during the shift so that the actual duration is equal to that 
> requested.

This is only true I think if you have a duration only expressed in terms of hours, minutes, seconds.
We need to define the behavior for the 3 cases:
 - a duration expressed in hours, minutes, seconds (dur-time) results in the same exact duration, regardless of the DTSTART
 - a duration expressed in days or weeks (dur-day, dur-week) may result in different exact duration depending on the DTSTART
 - duration expressed in a mix of days + hours, minutes, seconds (dur-date): same as for days or weeks since one would add days first, then hours/minutes/seconds.

> 	If the duration of the recurring component is specified 
> with the "DTEND" or "DUE" property, and the VALUE parameter 
> is DATE-TIME, then the duration applied to all members of the 
> recurrence set should be calculated as specified for the 
> "DTEND" component of the first member of the recurrence set, 
> including adjusting the duration because of the timezone 
> shift. If the duration is specified with the "DURATION" 
> property, then the duration should be that specified for the 
> "DURATION" property, and any calculations to determine the 
> end date and time of the member must make adjustments for any 
> timezone shift. For example, expansion of recurrence rules 
> with a DURATION property of one hour should always result in 
> individual members of the set with a duration of one hour, 
> and should not shrink to zero hours or expand to two hours 
> because of timezone changes.

With the changes above, that make sense.

Arnaud Q
> Subject: [Ietf-calsify] new section in recurrence rule 
> definition (exact duration versus nominal duration)
> 
> Hello,
> 
> I'm having a hard time trying to understand the following new 
> section in the recurrence rule definition at: 
> ) which summarized quite well my layman undestanding of the 
> difference between using DTSTART+DTEND versus 
> DTSTART+DURATION in a recurring event.
> 
> <<
> Case a:
> 
> Maybe my company will pay me for the 8 hours on days I only 
> work 7, thats an accounting issue, not a scheduling issue. 
> Either way, they don't have two chairs at the security desk 
> that I work at, there is no point me standing there looking 
> over the other guards shoulder. Our shifts do not overlap, on any day.
> 
> This is an example of when DTEND would be used. DTSTART is 
> when I start work, DTEND is when I end work, very simple, 
> always right.
> 
> 
> Case b:
> 
> What I thought was a clear example is in opposition with the 
> new calsify section, especially with the DTEND part:
> 
> "If the duration of the recurring component is specified with 
> the "DTEND" or "DUE" property, then the same exact duration 
> will apply to all the members of the generated recurrence set."
> 
> Has the meaning of a DTSTART/DTEND recurring event changed ? 
> Or is the example above plain wrong ? Or maybe I don't 
> understand the meaning of "exact duration" ? 
> 
> About the DURATION part, I think it would really help to 
> state (e.g. in the duration definition) what we mean by 
> nominal duration, for example (taking almost verbatim from 
> the ISO 8601 definition):
> 
> <<
> Duration can be expressed by a combination of components with 
> accurate duration (hour, minute and second) and components 
> with nominal duration (week and day).
> 
> The duration of a calendar week or a calendar day depends on 
> its position in the calendar. Therefore, the exact duration 
> of a nominal duration can only be evaluated if the duration 
> of the calendar years, calendar months, calendar weeks or 
> calendar days used are known.
> >>
> 
> Finally, in most cases, a DURATION will contain only accurate 
> durations and hence, all instances will have the same exact 
> duration. A few extra words could clarify that I think. 
> Something like:
> 
>       If the
>       all the members of the generated recurrence set. **If 
> this duration contains values with nominal duration**, the exact