Subject: Recap: Does 1 day == 24 hours?

From: Eric Busboom <[email-masked]>
Date: Fri, 20 Apr 2001 09:33:40 -0700 (PDT)

This is recap of the thread we had a few weeks ago regarding "Does 1
day == 24 hours" To review, the problem is that RFC2445 does not
specify what 1D really means when used in a DURATION. During the
discussion, there were three camps:

  1) 1D means 24H. In this case, 1D is a synonym for 24H. This means that
  DURATION values can always be expressed as a number of seconds, but you
  may get unexpected behavior when a DURATION crosses a timezone boundary:
  an event of DURATION:1D may start at 10:00 on one day and finish at
  9:00, 10:00 or 11:00 the next.

  2) 1D means "the remainder of today". In this case the W and D parts
  of the DURATION are an entirely separate scale from the time
  parts. The date parts always end on date boundaries. So a duration of
  2D will end at 24:00 tomorrow, and a duration of 1D on an event that
  starts at 23:50 will mean that the event lasts only 10 minutes.

  3) 1D means "the same time tomorrow" In this case, a meeting with a
  duration of 1D that begins at 10:00 will end at 10:00 tomorrow,
  regardless of any intervening time shifts. So, for the
  America/Los-Angeles timezone, the meeting could be 23,24 or 25 hours
  long, depending if the next day includes a time shift on to or off of
  daylight savings time.

Now, honestly, none of these options are very good. 

(1) implies that the end time of a 1D event can move around depending on
daylight savings time shifts, and it makes the W and D specifiers
redundant, since they can always be expressed in H, M or S.

(2) is logical, self consistent and non-redundant. It is the RFC
authors original intent, but I'd suspect that end users will find it
very strange. Are there use cases that require this behavior?

(3) may be more expected from the end-users perspective, but is
complex to implement, since you have to look for timezone shifts every
time you convert a DURATION of 1D into an end time. 

Personally, I'd reject (1). It is the easiest to understand and is
logical, but it doesn't add anything to the behavior of DURATION. If
we are going to define 1W = 7D and 1D = 24H, then we could just
condense the entire DURATION down to seconds. ( BTW, this condensation to
seconds in an implementation is what triggered the entire discussion. ) 

I prefer (2), but could live with (3). Both add useful behavior to
DURATION that cannot be accomplished easily with H,M and S. (3) is nice
because I think it best matches users expectations. I would naturally
expect that a 1D event that starts today at 10:00 will end tomorrow at
10:00, and (3) ensures this behavior.

However (2) makes more sense when the value of DTSTART is DATE. In fact,
it is probably sensible to restrict DURATION to only using W and D when
DTSTART:VALUE=DATE. This would eliminate any questions about what it means
to at 2H to a DATE. This points to strengthing the concept of time scale
vs date scale in RFC2445, and (2) would be an important part of that
concept. 

(2) is easy to implement, adds additinoal functionality, and although it
has unusual behavior for DTSTART;VALUE-DATE-TIME, it is a perfect match
for DTSTART;VALUE=DATE.

Which option do you prefer?

eric.

---

From: Alan Davies <[email-masked]>
Date: Mon, 23 Apr 2001 11:21:22 -0400

>vs date scale in RFC2445, and (2) would be an important part of that

This seems like a sensible suggestion- there should be a
clear link between the scale used for DTSTART and the scale
used for DURATION. All 3 interpretations that you summarised
have their good points, but suffer because they're either
ambiguous or too complex when used with mismatched calendar
scales.

I like the idea of strengthening the time scale vs date
scale concept. Date scale DURATIONs would in D(ays),
time scale DURATIONs in (S)econds.

Weeks could still be used to represent 7 days, and Hours
and Minutes the corresponding number of seconds, although
how much value do they add? Two reasons I can think of for
W, H, and M are that they increase human-readability of
the object (it's not immediately obvious to me that 43200
seconds is actually 12 hours), and possibly give some
implication about the precision (in a mathematical sense)
of the value- although this could be stated if it is
true.

(As a side note: it's not clear in RFC2445 whether durations
such as PT70S, PT60M etc. are allowed - i.e. with second/minute
components greater than 59. I can't see any text to disallow
them though.)

In a spec like this, should we be trying to avoid redundancy,
ambiguousity, and unnecessary complexity wherever possible?
One of the reasons for the rise in popularity of RISC processors
was that their smaller instruction sets were easy to prototype
and test. iCalendar implementations are not easy to prototype
and test.

--Alan

---

From: Damon Chaplin <[email-masked]>
Date: Mon, 23 Apr 2001 21:11:49 -0400

Eric Busboom wrote:

>   1) 1D means 24H.

>   2) 1D means "the remainder of today".

>   3) 1D means "the same time tomorrow"

I'd say use (3) as it is the most intuitive. Surely most iCalendar
apps out there already assume (3) anyway.

I can't see much use for (2), and if an app really wants that kind
of functionality it can convert it to a 'normal' duration or use an
end time instead or something.

Damon

---

From: John Stracke <[email-masked]>
Date: Tue, 24 Apr 2001 09:17:22 -0400

Eric Busboom wrote:

> condense the entire DURATION down to seconds.

By this argument, W, H, and M should all be eliminated in favor of D and S.

> Which option do you prefer?

(1).

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"There will be no more there. We will all be |
[email-masked]|here."--networkMCI ad                        |
\==============================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 24 Apr 2001 16:30:01 +0200

--On 01-04-24 09.17 -0400 John Stracke <[email-masked]> wrote:

> If

I have not read the whole thread (too much mail, and I always trust the wg
to do a correct job).

But, these things will _NOT_ pass the IESG.

One week is not the same thing as 7*24*3600 seconds. You have leap seconds
and changes to/from daylight savings.

If one say duration of one day, with start 12.32AM, the end is 12.32AM next
day, regardless of whether there have been a leap second, change in
daylight savings or whatever.

If the duration is not one day but 24*3600 seconds, the end time might be
something else than 12.32AM the next day.

    paf