[Ietf-calsify] Re: dtend removed?

Sam Roberts sroberts at uniserve.com
Tue Apr 5 21:05:34 PDT 2005

Quoting Chris_Stoner at notesdev.ibm.com, on Mon, Apr 04, 2005 at 01:39:24PM -0400:
> I don't think I really understand the Use Case.  Can you give me two
> examples of nursing shifts that you cannot express in iCalendar?  (or maybe
> not sure if you can express in iCalendar)

2 shifts a day, every day, with no overlaps or breaks between:

  DTSTART;TZID=blah:... april 1, 00 AM
  DTEND;TZID=blah:april 1, 12AM

  DTSTART;TZID=blah:... april 1, 12 AM
  DTEND;TZID=blah:april 1, 12PM

Works great the first day, but when the next day comes, how do you
calculate the end of that occurence?

The obvious way, calculating an implicit duration from the DTSTART/DTEND
of the first day and adding that duration to all future occurences, will
cause each shift to be 12 hours (assuming no DST oddities on the first
day of the event). But, not all days have 24 hours in them. So some days
will have hours not covered by a shift, and some will have hours covered

Other irregularities in the way we measure time cause similar symptoms,
such as leap years.

The solutions appears to be either:

a - saying that DTEND is just another way of saying DURATION (this leads
to Doug's suggestion of just deprecating DTEND and just putting the
DURATION in, since there is no difference)

b - outlaw RRULE, and allow only with RDATE which forces you to list
every single occurence in the RDATE (imo, this can't be taken seriously)

c - fix the problem if we can

d - change to a different calendar, maybe the French revolutionary calendar? :-)

e - ????

(c) would mean figuring out a way of having the above example "work".

Personally, I think expressing events as having a start and stop time is
a very common and human way of doing things, and so is worth supporting
if possible.

Nursing shifts is my example. If all you want to do with iCalendar is
express customer meetings, then just stating DURATION is enough, but is
the case of repeating shift work really such a fringe case that we can
ignore it?


More information about the Ietf-calsify mailing list