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

From: [email-masked]
Date: Tue, 27 Mar 2001 19:18:45 -0600

> > If you specify a duration of 1 day, then it ends at the end of the
> day,
> > right?
> >
> 
>     Do you mean to say that if I specify a meeting at 11:50 pm with a
> duration of 1 day, it should be interpreted to end 10 minutes later?

Graham:

A day ends at T235959 on that day. Right? At least this the logical
conclusion that I would draw. It is what I had in mind when this was
created.

If you want to specify a duration of 24 hours then you would use a duration
of such, rather than a day duration.

If I have a conference that begins at T090000 tomorrow and lasts for the
day, then I would expect it to _not_ go into Thursday, but be done on
Wednesday.

So, yes, I would expect that if you specified a meeting that began at
T235000 and had a DURATION of P1D, then it ought to end on the same day.

-- Frank

---

From: Alan Davies <[email-masked]>
Date: Tue, 27 Mar 2001 22:01:51 -0500

>day, then I would expect it to _not_ go into Thursday, but be done on

I wouldn't expect your conference to finish at midnight
though- I'd expect you to use a sensible duration of, say,
9 hours- so that you've got time for some dinner afterwards.
If it really finishes at midnight, you could use a 15 hour
duration.

Last week a flight of mine from Pittsburgh was cancelled at
11:30 on Thursday, and I eventually flew at 22:30 on
Friday. How would you represent the duration of my
stay, P1DT11H or P1DT22H30M ?

>T235000 and had a DURATION of P1D, then it ought to end on the same day.

Is a single day the only case that should be rounded up to
the next day, or does this apply to 2 day, 1 week, 1 month
etc. durations?

This isn't hinted at anywhere in RFC2445, although
the term 'day' is used freely as if it were as unambiguous
as 'hour' or 'minute', which it apparently isn't.

--Alan

---

From: John Stracke <[email-masked]>
Date: Wed, 28 Mar 2001 10:31:24 -0500

> >A day ends at T235959 on that day. Right? At least this the logical

[...]

> 9 hours

Er...what?

<insert expressions of amazement here>.

This thread is extremely surprising to me.  To me, it's obvious that a duration
is a scalar value that is equivalent to some number of seconds.  To take a
duration of one day and turn it into 15 hours, or 9 hours, or something, just
does not make sense to me.  (The "sensible duration" approach, in particular,
is fraught with peril; who decides what's sensible? The modern 8-hour work day
is a historical artifact left over from the "share the work" sentiment of the
Great Depression.)

An event with a duration of one day is not the same as an all-day event.  An
all-day event is just one that starts at midnight and ends at midnight (or 0900
and 1700, if that's what you prefer); it does not need any kind of special
syntax.  An event with a duration of one day is an event that lasts 24 hours.
It'd be a strange sort of person-to-person meeting, but so what? If iCalendar
were used only for person-to-person meetings, we wouldn't have durations
expressed in weeks, either; nobody meets with someone for three weeks without a
break.  (I was at IETF for a week, for example, but I wasn't meeting with
anybody at 0100; I put it on my calendar as a recurring event.)

To me, the duration should specify the actual length of real time that the
event will take.  If I tell my CUA I expect it to take 24 hours, then my CUA
should be free to express that as 1 day.  If I shift the start of the event and
leave the duration the same, the event should really take the same amount of
real time; it should not have some sort of floating DTEND that gets arbitrarily
pinned to midnight.

Am I the only one here who believes this?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Beware of wizards, for you are crunchy and good|
[email-masked]|with ketchup.                                  |
\================================================================/

---

From: Alan Davies <[email-masked]>
Date: Wed, 28 Mar 2001 10:36:06 -0500

I was saying the same thing as this, except maybe
I didn't type enough characters to make myself completely
clear.

My point was that there wasn't any added use in having
a P1D duration event finish at midnight, and that it
could cause added confusion and ambiguity.

What's your view on the 23/25 hour day when spanning
Daylight/Standard time shifts?

--Alan

---

From: John Stracke <[email-masked]>
Date: Wed, 28 Mar 2001 10:49:37 -0500

Alan Davies wrote:

> I was saying the same thing as this,

Ah, OK.

> Daylight/Standard time shifts?

Mmm, I think it should still be 24 hours long.  I would convert DTSTART to GMT,
add 24 hours, then convert back.  (I might have a more efficient way of doing it,
of course, but that's the result I'd be going for.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Time is money, and price is information."   |
[email-masked]|--Russ Nelson                                |
\==============================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 28 Mar 2001 11:04:30 -0600

I think that this is showing up a ambiguity that is present in RFC2445, most
calendaring applications, and in most users. I.E whether there is a
difference between - "This ends at the same time as it started shifted by X
days" vs. "This ends exactly 24 (or x*24) hours from when it started".

The difference is indeed subtle - only coming into play two days a year, and
only in those timezones where daylight savings occurs. (there is also the
case of years with a leap second - does 1 day equal exactly 24 hours and
does 1 hour always equal 3600 seconds?

In the case of durations - there could be a value to having both behaviours
possible - this event will take exactly x hours (which could be 24 or more
hours) as well as This event will last until this time tomorrow - which
means that on the days that overlap a daylight savings time shift the number
of hours is not equal to 24.

User interfaces COULD make this very clear to users - I don't see that it is
very useful to force implementations to equate these durations - since they
are both possible the applications should stick to what the user selects. It
is the responsibility of the implementation to show to the user the
difference.

There is the further concept of "for just this one date" or "all-day" which
I do NOT think should be set in the standard, but should be left to the
implementation to convert to the appropriate durations and start times (i.e.
DTSTART of just after midnight, DTEND of just before midnight for some
"all-day", or "DTSTART set by user and DTEND of just before midnight of that
date for "just this day" type of events." Since this is a user interface
issue - easily expressed under the current standards, I think it would be
poor use of duration: day to use it to mean one of the above meanings -
these should be converted and implemented by the application.

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 John Stracke
Sent: Wednesday, March 28, 2001 9:50 AM
To: [email-masked]
Subject: Re: Duration: Does 1 day == 24 hours?

Ah, OK.

> Daylight/Standard time shifts?

Mmm, I think it should still be 24 hours long.  I would convert DTSTART to
GMT,
add 24 hours, then convert back.  (I might have a more efficient way of
doing it,
of course, but that's the result I'd be going for.)

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Mar 2001 22:13:59 +0200

At 10.31 -0500 01-03-28, John Stracke wrote:
>An event with a duration of one day is an event that lasts 24 hours.

No, it's an event which lasts from say 1700 one day to 1700 the next. 
Just like one month after jan 2 is feb 2, and one month after feb 2 
is march 2.

You can not convert from one unit to another.

     paf

---

From: John Stracke <[email-masked]>
Date: Wed, 28 Mar 2001 16:26:03 -0500

> No, it's an event which lasts from say 1700 one day to 1700 the next.

That is one possible approach, but it's one that makes duration
calculations much more complex.  In this approach the duration data type
becomes polymorphic; it can be *either* days *or* seconds, and you need
drastically different code to deal with the two cases.  Add in durations
that are *both* (e.g., P1DT5H), and you're in deep pain.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"And bring the search warrant." "You mean the|
[email-masked]|sledgehammer, sir?" "Yes."                   |
\==============================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 Mar 2001 07:13:27 +0200

>that are *both* (e.g., P1DT5H), and you're in deep pain.

Calendar calculations are hard, and you can not ignore real life.

   paf