Subject: RE: Duration: Does 1 day == 24 hours?

From: [email-masked]
Date: Fri, 30 Mar 2001 08:27:58 -0600

Patrik:

Good comments on this point. Did you take into account that DTSTART can have
a purely date value, not just a date-time value? In this case, changing the
DURATION to seconds (or clock time) would not make any sense. FYI.

In any case, I concur with Graham that restricting DTSTART and
DTEND/DURATION to be values with the same calendar/clock scale makes sense.
There appears to be no explicit requirement to maintain this flexibility and
the limitation will minimize the complexity of comparisons and will probably
assist in facilitating interoperability.

-- Frank

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 Mar 2001 16:55:52 +0200

>DURATION to seconds (or clock time) would not make any sense. FYI.

This has nothing to do (from my point of view) with what I wrote.

I talked about the need for pointing out the danger of translating 
one unit in the duration to another. For example from Minute to 
Seconds, or Month to Days.

>assist in facilitating interoperability.

Can you have a recurrent event with a duration?

    paf

---

From: "Mark Mansour" <[email-masked]>
Date: Fri, 30 Mar 2001 09:55:55 -0800

This is my first post, so be kind :)

I am struggling to see why duration is even required.  Why have two ways to
define an events end datetime (start + dur or end)?  As far as I can tell an
event's bounds can be defined by only the start time and an end time (not
thinking about repeats here).  The inclusion of duration seems to just
confuse the matter.

In Patrik Faltstrom example F (One day after 2.30AM Mar 31, 2001 in San
Francisco is ???? (2.30AM Apr 1, 2001 doesn't exist this year in San
Francisco)) why even allow people to reach a conclusion of a 2.30Am Apr 1,
2001 date?  If you are only allowed to select a start and end date then
2:00 - 2:59 can be hidden from the user.

BTW : I am still struggling through the iCalendar spec so I may have missed
something obvious, but I have implemented a calendaring system and duration
is not something we ever used.

--
Mark Mansour                 [email-masked]
Flypaper - Faster Business
Visit http://flypaper.com to learn more...

---

From: Alan Davies <[email-masked]>
Date: Fri, 30 Mar 2001 13:32:19 -0500

>thinking about repeats here).  The inclusion of duration seems to just

I agree. Apart from some obscure subtleties to do with
Daylight/Standard Time changes, the same information can
be expressed using either DTEND or DURATION. Why do we need
both?

By the way, Outlook 2000 ignores DURATION altogether,
and I believe Outlook 97 ignores DTEND. =:-0 This situation is
not the fault of RFC2445, but redundancy in the spec
allowed the two products to implement incompatible subsets.

>2:00 - 2:59 can be hidden from the user.

Times can be specified in iCalendar as 'floating', which
means that no timezone is specified. Maybe 2.30AM Apr 1, 2001 is
a valid time in my timezone, but not in yours- the spec should
tell you how to handle this case, but doesn't.
Maybe floating times are a bad idea anyway- would it be too restrictive
to say that times had to be in a specific timezone (with UTC
being a good choice for all but recurring events)?

Also, iCalendar isn't really concerned with UI issues, although it
would be nice if your UI did something along the lines of preventing
you from creating an event at a non-existent time (assuming the
timezone had been specified in your UI of course).

--Alan

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 30 Mar 2001 12:48:13 -0600

I agree that any duration could be expressed as a start and end time. But a
few examples where this could get complex from a user's perspective.

One - how do you enter into a system a plane flight. It is fairly easy to
consider it as the following: I leave Chicago at 9:00 AM, the flight lasts 7
hours, after which I am in Paris. As a user, it is not so easy for me to
enter in a START time in Chicago (presenting NOT under DST) and an END time
in PARIS (presently under DST I believe) - it gives me headaches trying to
figure out what the END time would be in Paris' timezone.

Two - If from the user's perspective the crucial information is that the
activity will take 4 hours - how could a calendaring system differentiate
that case (Start time, event that has to last hours) from a similarly
entered event where the start and end times are what is important.

	In the first case, if you change the START or END time - the other time
should be adjusted accordingly - the two times are joined to each other with
a requirement that there is consistent difference between them.

	In the second case, you can change the START or END time, and there is no
requirement that the other time change (though if the "end" time is BEFORE
the "start" time we may have to rename the two times.

Three - Is there a requirement that DTSTART and DTEND times be in the same
form? I.E. is it REQUIRED that we can determine that in fact the DTSTART
occurs BEFORE the DTEND? this means for example that each time must have a
timezone if one time has one, that if a DTSTART includes hours and a date,
the DTEND cannot simply be that same date - it must also have hours.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark Mansour
Sent: Friday, March 30, 2001 11:56 AM
To: Patrik Faltstrom; [email-masked]
Cc: [email-masked]
Subject: RE: Duration: Does 1 day == 24 hours?

---

From: Eric Busboom <[email-masked]>
Date: Fri, 30 Mar 2001 15:04:45 -0800 (PST)

> be expressed using either DTEND or DURATION. Why do we need

DTEND and DURATION are equally expressive, but they mean different things
with respect to changes.

DURATION means the event has the specified length, regardless of when it
starts. If I have an event with a 1 hour duration and I move its start
time back 30 minutes, it is still a 1 hour event.

DTEND means that the event has the specified ending, regardless of the
duration. If I have a one hour event and I move its start time back 30
minutes, I then have a 30 minute event. 

We need both because people have both conceptions of the length of an
event. If you absolutely must leave the meeting at 3:50, the use DTEND. If
you want the meeting to last an hour, use DURATION. 

Use of DURATION also lets you get around changes in timezones when you
travel. If the length of a flight is specified as a DURATION then you can
defer timezone change calculations until later. 

We could handle both cases without DURATION if we added a parameter to
DTEND ( or DTSTART)  to indicate if DTEND should be changed when DTSTART
is changed, but I think DURATION is more direct.

eric.

---

From: "Mark Mansour" <[email-masked]>
Date: Fri, 30 Mar 2001 15:20:50 -0800

> you want the meeting to last an hour, use DURATION.

I can't help but think this is a UI issue.  I believe that an explicit start
and end date are all you need to store.  If a 1 hour event is rescheduled
AND that event is to remain as 1 hour in duration then the UI should enforce
that rule and just send the start and end date to the backend.

Mark

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 31 Mar 2001 20:53:02 +0200

>that rule and just send the start and end date to the backend.

If you have a repeating event which starts at 1.30AM every day, and 
is one hour long. How do you specify the end-time if we do not have 
duration if the repeating events will be also on nights when daylight 
savings rules changes?

    paf