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

From: [email-masked]
Date: Wed, 28 Mar 2001 23:40:57 -0500

Has anyone considered a 'work-week' function - instead of a seven day
period, rather have only a Mon to Fri work week (configurable by the user)
I picture this being used in freetime or busytime searches. I am thinking
of real-estate on any interface given to any apps using iCal... having only
5 display days would allow for more things on-screen.

Any thoughts?

=========================
Don Andrews
Senior Specialist, Internet Messaging Strategy
Canadian Tire Corporation
Office: (416) 480-3934 Fax: (416) 480-8257 Pager: (416) 375-8237
Email: [email-masked] Web: http://www.canadiantire.ca

|--------+-------------------------------->
|        |          "Graham Gilmore"      |
|        |          <[email-masked]> |
|        |          Sent by:              |
|        |          owner-ietf-calendar@ma|
|        |          il.imc.org            |
|        |                                |
|        |                                |
|        |          28/03/01 06:53 PM     |
|        |                                |
|--------+-------------------------------->
  >-----------------------------------------------------------------------------------------------------------|
  |                                                                                                           |
  |       To:     <[email-masked]>                                                                     |
  |       cc:                                                                                                 |
  |       Subject:     Re: Duration: Does 1 day == 24 hours?                                                  |
  >-----------------------------------------------------------------------------------------------------------|

>
> OK, I think we're nearing the problem here: as far as I can see,
scheduling an
> event for a date, with no time, makes no sense.  Actual events occur
in actual
> periods of time.  That period might be "midnight to midnight, 28 Mar.
2001,
> EST", but it's still a period of time.  What extra capabilities do we
get out
> of supporting DATE values?

    We've been here before.

    DATE value types are perfect for things like birthdays, holidays,
and other such types of events.  These types of events don't really have
an associated timezone, and often are "in effect" for the entire
duration of the day ( i.e. P1D :P ).  Alternatively they are useful to
specify the date on which a particular instant of time occurs, without
knowing or needing the exact time of day at which it occurs - for
example, I might have a note in my calendar which informs me that on
March 31st, a colleague returns from an overseas trip.

    Graham

---

From: John Stracke <[email-masked]>
Date: Thu, 29 Mar 2001 11:49:30 -0500

> period, rather have only a Mon to Fri work week (configurable by the user)

This would be a user-interface issue, not an iCalendar issue.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Q: What goes "Pieces of 7! Pieces of 7!"? A: A|
[email-masked]|parroty error.                                |
\===============================================================/

---

From: "Graham Gilmore" <[email-masked]>
Date: Thu, 29 Mar 2001 13:43:13 -0500

I think in the interests of clarifying the iCalendar spec, and
keeping the chances of interoperability high (not to mention our sanity
level :) it might be a good idea to disallow DURATIONs with day or week
components from being used with DTSTARTs that have DATE-TIME values.  In
any case, any effect that people might want to achieve with such a
combination can be replicated with DTEND (which is completely
unambiguous across DST boundaries, provided DTEND isn't IN the DST
boundary - but that's another matter :) .
    Can anyone think of a situation where combining these kinds of
representations can't be more clearly expressed another way?  Any good
reason for NOT removing them?
    (We might also consider the combination of a DURATION with time
components with a DTSTART specified as a DATE value, but I'm not sure
that there would be any other way to express something like that -
provided we can agree on what it expresses in the first place :)

    Graham

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 Mar 2001 14:41:57 +0200

>provided we can agree on what it expresses in the first place :)

The question is even more generic, and here is a try:

When having a duration specified in one unit, should that unit be 
translated into some one standard unit (like seconds) before being 
added to the DTSTART?

My take is that if the duration is for example "one day", exactly 
"one day" should be added to the DTSTART, and not 24 hours or 24*3600 
seconds, or ending at the next start of a day after DTSTART. I.e. the 
units used in the specification of "duration" can not be changed to 
other units without taking into consideration the context, and this 
because the length of the duration in other units varies over the 
year. One can not say how many seconds there is on a year, or hour, 
or day -- just as one example.

As Graham is saying, this can be implemented via DTEND, but I still 
think it has to be specified how this is supposed to work. A few 
examples could help, like:

A. One month after Jan 13 is Feb 13
B. One month after Feb 13 is Mar 13
C. One day after 6.30PM on Jan 13 is 6.30PM on Jan 14
D. One week after 6.30PM on Jan 30 is 6.30PM on Feb 6
E. One day after 1AM Mar 31, 2001 in San Francisco is 1AM Apr 1, 2001
You also have to say what for 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)

    paf