Subject: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 2 20:46:37 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050402/4da144a7/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 2 20:50:27 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050402/56bccc8e/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sat Apr 2 22:26:38 2005

Quoting [email-masked], on Sat, Apr 02, 2005 at 09:46:24PM -0700:
> 
> 
> Sam Roberts wrote:
> >Quoting [email-masked], on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> >
> >>I send -01 of iCal-Basis to the IETF. It fixed some problems and
> >>typos that were sent to me and the lists. It also deprecates DTEND and
> >>replaced the examples and ABNF with DURATION.
> >
> >
> >dtstart/dtend and dtstart/duration are equivalent ONLY for single
> >non-recurring events.
> >
> >A yearly event on that starts at april second   3PM, and goes until
> >april 3 6PM will have different durations. This year it falls on
> >DST. The duration will be different next year.
> 
> It can't as not all time zones change at the same time. Your doing
It can't "what"?
> the math in the TZ and that can product different results across
> time zones for the same instance. You have to convert each instance
> to UTC, then do the math to make it work in all TZ's. Then you will see
> that the all have the same duration.

You seem to be talking about the event in different timezones. I'm
talking about the event in one timezone, but with multiple occurences.

If I have an event from 1AM to 11AM, on Aprils 3rd, it's duration will
be 9 hours, in 2005.

In 2006, the duration will be 10 hours.

So,

  DTSTART:20050403T010000
  DURATION:P9H
  RDATE:20050403,20060403

This year, it will end at 11AM, next year at 10 AM.

Your choice to prefer duration over dtend appears based on the assumption
they can represent the same information.

Are you sure this is the case? It sure doesn't look like it to me.

Quoting [email-masked], on Sat, Apr 02, 2005 at 09:50:17PM -0700:
> >Anything starting on the 25th and going to the "-1th"/last day of the
> >month will have a different duration every month. Etc.
> 
> 
> However, I do not know of any CUA that can set the DTEND to that value.
> At the very least it is not in most products. And it is a great example.
> In my entire life, I have never needed to set such an end time for
> anything.

This has nothing to do with DURATION, but you've never had an event that
ended on the last day of the month? Thats weird, having things end on
the last day of the month is probably almost as common as starting on
the first. What about quarter end at your company, not an event? Doesn't
end on the last day of a month? Doesn't repeat? Or your pay periods,
they don't go from the 15th to the end?

> CALSIFY is about what we "NEED", not what we might want to do.

Right, so back to the DURATION issue.

I need to represent events that start at X o'clock, end at Y o'clock,
each time they occur, and I don't think I can with DURATION.

> We need it to work with most products.

A product that can't calculate dtend from dtstart/duration or duration
from dtstart/dtend won't interoperate with anything.

A programmer who can't add and subtract times can't implement a calendar
spec.

Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 3 00:03:08 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/dd9830ac/smime.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 08:25:53 2005

> Sam Roberts wrote:

I removed my example, and used yours, since it shows the problem with
the reductionist approach so well.

> Lets say you work a 10pm - 6am work shift and are allowed
> to eat at 1am - 2am.

The example above is a concise example of why both representations are
necessary, simply understood, and model different things.

Case a:

  A shift of work: 10pm - 6am. This is when I work, those times being in
  my local timezone. Most days my shift will be 8 hours long, on
  occaisonal days it will be 7, and on others it will 9.
  
Maybe my company will pay me for the 8 hours on days I only work 7,
thats an accounting issue, not a scheduling issue. Either way, they
don't have two chairs at the security desk that I work at, there is no
point me standing there looking over the other guards shoulder. Our
shifts do not overlap, on any day.

This is an example of when DTEND would be used. DTSTART is when I start
work, DTEND is when I end work, very simple, always right.

Case b:

  My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get
  more or less.

This is an example of when DURATION would be used. You still allow this.

To answer your questions:

> Even with DTSTART and DTEND do you think your employer will allow you
> to take two hours in the rare cases that the TZID changes on those
> times?

No, breaks have a DURATION, not a start time and end time.

Your one size fits-all attitude would cause this problem, not fix it.

> Would you accept the fact that on other rare dates you can't
> eat at all because the 1am-2am went away?

So at 1AM, people set their clocks forward to 2am. But I set DURATION,
so 1 hour later is 3AM on this day, and I get the same time to eat
I get every other day.

The above point would be valid if you had chose to allow only
dtstart/dtend. In which case I would be complaining about that, but the
above case works fine with DURATION.

> Or do you have to be there 9 hours ether way? Or maybe 8 hours on rare
> dates, or 10 hours on rare dates.

Exactly.

> Will you accept the fact that you do not get paid for one of the hours
> because the TZID shifted back one hour?

I may file a union greviance, but there isn't room for two people to sit
at the guard desk, and there must be a guard there every hour of the
day, whether there are 23 or 25 hours in the day.

How I get payed for this is a problem well outside of the scope of
iCalendar! Probably, I don't get paid enough.

> It can represent the same information. Just perhaps not in
> exactly one object. So ether way you have the multiple
> TZID across time shift problems. Few CUAs allow the user
> to select DTEND or DURATION.

You started off wanting to make things simple, and now you've introduced
the need for multiple objects, sometimes?

You started off by wanting to increase inter-operability, and now state
that half the implementations out there are non-compliant?

> THE REAL PROBLEM:
> 
> 	YOUR-BOSS-CUA-WORK generates DURATION.
> 	YOUR-CUA-WORK generates DTEND.
> 	
> 	So your boss tells the company calendar you will be
>         here 10 hours on that rare day when DURATION is
>         longer. Saved as 'floating time' appointment.
> 
> 	You read your company calendar with YOUR-CUA-WORK
>         which converts a DURATION to a DTEND for display. It notices
>         the TZID shift and subtracts out the hour to display
>         the correct time and it uses the end time as the
>         display time.
> 
> 	Your fired - you left work early.
> 
>         Should your CUA have calculated the shift based on
>         the start time? End time? Duration? Was your CUA
>         busted? Your bosses CUA bused?

If my boss specified I work for 8 hours his CUA should have encoded it
as he specified it (with dtstart/duration) - in which case I better work
8 hours.  My CUA will add 8 hours of duration to the dtstart, do it
correctly for my timezone, and display when the event ends on that
particular day so I quit at the correct time. Anything else is wrong.

If my boss specified that I work from 10PM to 6AM, his CUA should have
represented it as such, and my CUA better show my shift ending at 6AM.

> CALSIFY - lets all do it exactly one way.
> With DURATION all calculation have to be done relative
> to the start time. It has to, there is no end time.

The world doesn't work in one way.

Hospitals have 3 shifts a day, ending at fixed times, and not
overlapping.

Offices have 1 shift, starting at 9AM, and we work for 8 hours, no
matter when the end time is after 8 hours.

RFC2445 allows both to be trivially representable.

Your draft makes one trivial, and the other has to be represented as 3
objects.

To generate a shift that goes from 10PM to 6AM, every sunday of the
year, I have to notice that timezone changes on some sundays, generate
one event with a duration of 8 hours, exclude that event on all days in
which timezone changes occur, then put two other events, one with a
duration of 7 hours, the other with a duration of 9, that occur on
single sundays in the year, the DST adjustment days.

> NO CUA I have found says:
>  "I know you specified an DTEND time, however the time shift occurs
>   on that night, do you want to adjust it or not?"
> 
> Same problem with DURATION:
>  "I know you specified an DURATION, however the time shift occurs
>   on that night, do you want to adjust it or not?"
> 
> Your CUA can not tell why you entered the value.

The CUA doesn't have to do this, it should represent it exactly as the
BOSS entered it.

The problems you describe are all problems in conversion between the two
kinds of natural events, those with a fixed end, and those with a fixed
duration.

Since you propose to allow only one kind of representation, all the
problems you describe above occur. If you allow the two representations,
they don't occur.

This situation is CAUSED by your proposal, not fixed.

And a CUA that only allows inputting start and duration is incapable of
allowing my boss to input my shift that starts at 10PM and ends at 6AM.

This is a problem with that CUA, it is not a problem with RFC2445. Once
it's users complain, the CUA will implement events that end at a
specific time.

If you mention this issue in RFC2445bis, people might implement it
correctly the first time.

> >Are you sure this is the case? It sure doesn't look like it to me.

1 -

> I still think so, again perhaps not in exactly one object.

2 -

> I do think we need to reduce the number of ways to do
> exactly the same thing to 'one'.

Statements 1 and 2 are in direct conflict. One says there will be "one
way" to represent an even, the other says that in cases of events crossing
timezones the CUA will have to notice, and generate more than one
object. This is not "one way".

Why are you removing simple things that work well?

There are things in RFC2445 that are complicated, this isn't one of
them, leave it alone.

Sam

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Apr 3 09:03:20 2005

> RFC2445 allows both to be trivially representable.

Really? I looked at rfc 2445 and tried hard to find out how the end date of 
the recurrences is really calculated. I couldn't find anything definitive in 
the rfc. However, for recurring to-dos, rfc 2446 is quite clear on the 
calculation of the due date of the recurrences. See section 4.5.7.1:
"Calculating due dates in recurring VTODOs"

It is made clear to me that the calculation of the due date always implicitly 
uses the duration, which is either given, or directly calculated from the 
given dtstart and dtend (or due) of the very first occurence. 

BTW, several weeks ago I argued exactly the same ways as you did. I couldn't 
find any hint in rfc 2445 about how to correctly calculate the end date of 
events. And since the only reference was the due-date calculation in rfc 
2446, which doesn't allow your Hospital example (and since Doug also gave 
some sample calculations where he always implicitly used the duration to 
calculate the DTEND), I simply gave up resistence. 

I'd like to have a clear section in rfc 2445 about how the DTEND is calculated 
correctly. And if it is really the case, that all calculations only use the 
duration (explicitly or implicitly if a DTEND is given), we should make it 
very clear that the first example (where the shift always ends at the same 
time, so it might be one hour shorter or longer for the nights when DST 
changes) is simply not possible with iCalendar.

BTW, I don't think that this case will never be needed. E.g. take a schedule 
for the heating of a building. During the night the heating will be turned 
off e.g. from 10 pm to 7am (or the alarm will be set, or the door will be 
locked, or the cleaning crew will work from 10pm to 7am, or whatever).  When 
the DST starts/ends, you definitly don't want the cleaning crew to be still 
working or the alarm still engaged when all workers come to their office at 
7:30am. So these would be examples where the duration is irrelevant, but the 
DTEND is the crucial information. 
But then, I'm not sure if there is really a unique way to calculate the DTEND 
without using the duration...

> Your draft makes one trivial, and the other has to be represented as 3

It's already the same in rfc 2445. Either I'm missing something, or rfc 2445 
is simply lacking this capability (as strange as it may seem considering how 
over-engineered it is).

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/73c9144f/attachment.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 10:13:40 2005

Quoting [email-masked], on Sun, Apr 03, 2005 at 06:03:05PM +0200:
> However, for recurring to-dos, rfc 2446 is quite clear on the

I haven't implemented much of iTIP, and section 4.5.7.2 is so bad
grammatically I'm not sure what it is supposed to mean.

  "...the interval of one day which is applied to..."

This is either an incomplete sentence, or the "which" should be
dropped.

> changes) is simply not possible with iCalendar.

Ok, I thought about this some more, and looked at 4.5.7.2.

So, the issue is that in the 2nd occurence, you have applied the RRULE
to the DTSTART, so you know the 2nd start. But now you need to find the
2nd end. If you do this by calculating an implicit duration from the
first DTSTART and DTEND, it will be wrong over DST, leap years, etc.

Do I understand your point?

That is a serious problem, and if an algorithm can be specified, it
should be.

Events with a start and end time are probably among the most common
types of events. People do things like that, it reflects our lives.
iCalendar needs to represent it, its not a corner case, its a common
one.

I am very concerned that the goal of this RFC244x simplification is to
produce the simplest protocol that people can schedule meetings with.

I don't use iCalendar for meetings, I use it to represent events in my
life, many of which are repeating, and with alarms to notify me of their
recurrence - birthdays, holidays (first monday in July, etc.), when I
have to be at work, etc.

> DTEND is the crucial information. 

I'm not sure what you mean. You say "this case will never be needed",
but then give an example where DTEND is crucial. Whats the unnecessary
case?

Cheers,
Sam

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Apr 3 11:00:11 2005

Am Sonntag, 3. April 2005 19:13 schrieb Sam Roberts:
> > BTW, several weeks ago I argued exactly the same ways as you did. I
> > couldn't find any hint in rfc 2445 about how to correctly calculate the
> > end date of events. And since the only reference was the due-date
> > calculation in rfc I'd like to have a clear section in rfc 2445 about how
> > the DTEND is calculated correctly. And if it is really the case, that all
> > calculations only use the duration (explicitly or implicitly if a DTEND
> > is given), we should make it very clear that the first example (where the
> > shift always ends at the same time, so it might be one hour shorter or
> > longer for the nights when DST changes) is simply not possible with
> > iCalendar.
>
> first DTSTART and DTEND, 

Exactly. 

> it will be wrong over DST, leap years, etc. 

I wouldn't say it's wrong. Rather it needs to be clearly worded that the DTEND 
calculation always uses the duration, so the end time is not carved in stone. 

The same problem also appears with Feb 29. 
Here in Austria you get your yearly payment report sometime mid-february, and 
you have to submit the tax sheets at the end of May. Now imagine you create a 
yearly recurring todo for this, which starts on Feb 15, 2004, and has a due 
date of May 31, 2004. In 2005, due to the algorithm described in rfc 2446 
this event will have a due date of June 1, 2005, and you'll submit your tax 
sheet late (and you'll be prosecuted, sentenced to death and executed;-) )

One particular reason why the duration is always used might be recurring 
events that end on 2:30 am. When the time changes from standard time to 
summer time (and vice versa) you'll have either two 2:30am or no 2:30am at 
all. What shall happen to these events? When will they end?

> > BTW, I don't think that this case will never be needed. E.g. take a
> > schedule for the heating of a building. During the night the heating will
> > be turned off e.g. from 10 pm to 7am (or the alarm will be set, or the
> > door will be locked, or the cleaning crew will work from 10pm to 7am, or
> > whatever).  When the DST starts/ends, you definitly don't want the
> > cleaning crew to be still working or the alarm still engaged when all
> > workers come to their office at 7:30am. So these would be examples where
> > the duration is irrelevant, but the DTEND is the crucial information.
>

Okay, sorry I used a double negation, which in German (my mother tongue) is 
understood as a positive affirmation. I intended to say "I think this is a 
case with some real-world cases, so I don't think we can just ignore it". Or 
put differently, I wanted to negate the previous arguments by Doug on the 
list that all workshift-related events will not need a fixed end time. (But 
then, life doesn't only consists of work...)

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/2fb34ba6/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 3 13:45:03 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/c3766813/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 14:05:03 2005

It's also trivial to support doing the calculation of duration/dtend for
a specific event.

Do you ever intend to support recurring events again?

I just hours ago wrote a little server that publishes all the birthdays
in my address book as text/calendar over http, which is handy because my
calendar program now subscribes to it. Those birthdays recur!

Sam

> Copy at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.txt
> 
> And HTML version at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.html
> 	
> -- 
> 
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
> [email-masked]                 | Office: (208)612-4638
> http://Royer.com               | Fax:    (866)594-8574
>                                | Cell:   (208)520-4044
> 
>               We Do Standards - You Need Standards
>

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 3 14:17:18 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/5e8b372a/smime.bin

---

From: tantek at technorati.com (Tantek Çelik)
Date: Sun Apr 3 17:48:39 2005

+1

I concur with Sam's examples and conclusions.

If interoperability is the primary goal of this endeavor rather than 
theoretical reductionist simplification, then we should keep DTEND.

Thanks,

Tantek

P.S. The popular "iCal" built-in application on MacOSX generates DTEND.

--
Tantek ?elik
Senior Technologist, Technorati, Inc.

On Apr 3, 2005, at 8:25 AM, Sam Roberts wrote:

> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 3 18:02:26 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/e8e7fd0c/smime.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 3 20:18:48 2005

Quoting [email-masked], on Sun, Apr 03, 2005 at 07:02:15PM -0600:
> Tantek ?elik wrote:
> The only thing proved is that nether DTEND or DURATION solves
> the problem.
> 
> The real problem he found was that there is no one way
> to solve the problem of floating time events that
> occur access a time zone change.

DURATION is a good solution for fixed-duration events.

> We need to define the TZ math rules in the spec. Even
> with DTEND, it sill does not work all of the time.

DTEND is the beginning of the solution for fixed-end events. It has
problems, they should be fixed.

Saying there is no way in iCalendar to represent very common event
occurences such as a work shift doesn't seem like it will broaden
acceptance.

When a hospital wants to represent its nursing shifts as recurring
events, an iCalendar doesn't do it they have two choices:

 - throw iCalendar away, which would be a pity
 - extend the meaning of iCalendars to support this

This group should define the meaning of recurring events with DTEND, to
avoid ad-hoc implementations by implementors.

Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 3 21:13:47 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/da71371d/smime.bin

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Sun Apr 3 22:26:30 2005

I'm curious, are there any clients with UIs that are capable of making 
the distinction between those two kinds of user intent?

Lisa

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 4 00:05:19 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050404/d9be432d/smime-0001.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Mon Apr 4 07:28:39 2005

Hi Lisa,

> the distinction between those two kinds of user intent?

I allow a user to choose whether to set an end time or a duration on an 
event (the default for new events being duration). The client will then use 
DTEND or DURATION in the resulting VEVENT depedning on what the user used. 
When an event is edited, we detect whether DTEND or DURATION is present and 
set the UI fields accordingly. Thus if a user uses a duration in an event, 
when they come back to edit it they will see the duration active rather 
than the end time. Of course if some other client comes along and changes 
DURATION into DTEND, then we loose that state.

-- 
Cyrus Daboo

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Mon Apr 4 10:39:37 2005

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)

We (Notes) might be able to express this in our UI in release 6 going
forward if this is what I think it is...
Thanks-
CS

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Apr 4 19:50:06 2005

Putting in my two (okay, maybe one-and-a-quarter) cents worth:

It doesn't really matter that much, for calsify, what the UI can accept 
from, or express to, the user. The main goal of calsify should be to find 
what should pass from one piece of calendar code, whether it's a CUA or a 
CS,  to another.  If a UI supports incredibly complex definitions of 
appointments, whether using DTEND, DURATION, RRULEs, or whatever, the 
CUA/CS still needs to be able to pass it to another CUA/CS using whatever 
we determine the basic interoperability spec to be. For me, that means the 
use cases we should be discussing should not be UI-dependent.

> > > avoid ad-hoc implementations by implementors.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Apr 5 14:17:39 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050405/319484a7/smime.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Wed Apr 6 05:32:29 2005

> 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
  RRULE:FREQ=daily

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

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
twice.

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?

Cheers,
Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Apr 7 12:36:36 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050407/e8f648dd/smime.bin

---

From: tantek at technorati.com (Tantek Çelik)
Date: Thu Apr 7 13:57:51 2005

On Apr 7, 2005, at 12:36 PM, Doug Royer wrote:

> Did I miss any other options ?

I think the problem here is one of perspective: 
programmer-centered-design vs. user-centered-design.

>
> I still think this means we can eliminate DTEND. If there is
> exactly one instance, both DURATION and DTEND mean the same thing.

Agreed, except they mean different things to people.

Frankly, *people* treat events differently when they discuss them 
having a duration vs. having an end time.

E.g. some events start at a certain time, e.g. 8pm and last 2 hours, 
and if the event starts late (8:15pm), it still lasts two hours, and 
ends up ending at 10:15pm.

Other events start at a certain time, e.g. 8pm, and have a hard stop 
time, e.g. of 10pm, (e.g. a meeting room conflict, or a restaurant 
closing time etc.), so that if the event starts late (8:15pm) it still 
ends at 10pm.

So, for practical purposes, the concepts that DURATION and DTEND 
represent don't mean the same thing, and attempting to excise one will 
simply mean that you can't represent some real world situations.

The user-centered solution would ask the question of how do people 
treat duration and end time differently (if at all), and if so (e.g. as 
shown above), build the solution to take it into account.  People's use 
cases drive the solution rather than the other way around.

The programmer-centered-solution is what you wrote:

>
> When there is more than one instance, the originating CUA MUST
> specify the start and duration (even if by end time) of each
> additional instance. Once that is done, there is no point
> in having a DTEND that can only be used for the 1st instance.
>
> I assert that if an Organize GUI and CU want explicit end times,
> then the Organizer GUI and CU MUST set those for all instances.

With all due respect, if this translates into the user having to know 
when a shift crosses a time zone boundary and make adjustments 
accordingly, this is ridiculous.  And if the CUA doesn't automatically 
"do the right thing", then the user (or others involved with the event) 
will be quite upset -- see previous emails on the thread.

This is the problem with programmer-centered-solutions.  You are asking 
people (CU) to behave in a particular way in order to match the 
solution.

Your last sentence clearly points out the problem when you say "CU 
MUST".

"CUA MUST" is greatly preferable to "CU MUST", and every "CU MUST" is a 
likely usability problem.

Tantek

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Apr 7 15:50:05 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050407/28a72a15/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Thu Apr 7 20:25:27 2005

Quoting [email-masked], on Thu, Apr 07, 2005 at 01:36:22PM -0600:
> 
> The real problem is that the viewer of a VEVENT
> can not tell if the organizer meant that the end
> time is fixed or if the duration is fixed for the
> 2nd and higher instances.
> 
> How about this:

Your proposal basically boils down to:

a - specify that when dtstart/dtend is used, it is an alternate notation
for period for the first recurrence

b - explicitly list every single occurence with:
  - its duration
  - its end time
  - neither, in which case the occurence has the same duration as the
    first event
    
This seems to assume the RRULE is some kind of anachronism, best replaced by
RDATE. I get this general impression you feel this way from also from
your draft, in which you chopped it out, and with all your recurrence
examples, in which you laboriously write out the RDATE for each
occurence instead of doing the simple "FREQ=weekly". Perhaps I
misintepret your feelings about RRULE?

In the calendars I've seen, RRULE is the most common way to express
recurrence (I confess: I've never seen an RDATE, but that might because
OS X iCal never outputs one, so its not a good basis to say its not
widely deployed).

Anyhow, my calendar is full of things that recur indefinitely. The
encoding space used to represent a weekly recurring sunday event goes
through the roof, I don't think forcing CUAs to manually encode them
is such a great option.

I'd like to see an approach that states that when DTSTART/DURATION is
used with an RRULE, then each recurrence is of DURATION.

When DTSTART/DTEND is used with an RRULE, then you do <....> to figure
out the implied endtime of each recurrence.

So, what can <...> be? I'll spend some time thinking about it this
weekend.

Cheers,
Sam

p.s. RRULE is an incredibly powerful and useful part of iCalendar, I've
implemented it, others have, and I'm not giving it up easily. Its
biggest problem is it is very poorly documented, and this should be
addressed by RFC2445bis.

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Apr 7 20:51:15 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050407/b0387a78/smime.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sat Apr 9 09:11:00 2005

Wrote Doug Royer <[email-masked]>, on Thu, Apr 07, 2005 at 09:51:03PM -0600:
> And as you have pointed out on this mailing list RRULE has
> exactly the same problem with the 2nd and up instances
> occur across time zone changes.

Hey, I never said that!

You've stated a few times now that RRULE can't work with floating
events, even when specified with DTSTART/DURATION, but I don't think
I've seen the problem described. Can you give an example detailing the
problem you see, or comment on my example below?

I do see a problem with RRULE and fixed-end time events (DTSTART/DTEND
specified), the KDE developer clued me in to that problem.

> Even if RRULE says, it still does not fix the repeating
> floating event bug you found.
> 
> This is NOT an RRULE, DTEND, DURATION, RDATE bug.
> This is a bug in that 2445 does not document HOW
> to define the end time (or duration) of the 2nd
> and higher instance so that if they occur across
> a time zone change, everyone displays the same
> end time (or duration).

"across a timezone change".

Do you mean when I'm flying on a jet and cross a timezone, or do you
mean a DST clock-shift?

"everyone displays the same end time (or duration)"

Recurring start and end times are either the same or not the same,
depending on whether you consider 9AM in Paris to be the same time as
9AM in Toronto. Its not the same for the purposes of having a
teleconference (so TZID must be published for a meeting), it is the same
for the purposes of making sure you are at work on time (so TZID must
NOT be published for these kind of events).

What do you mean by "same"?

> The problem is that NO RFC or draft currently tells
> the implementor HOW to compute the end time or
> duration of the 2nd and higher instances.

It seems pretty clear to me, so either I'm assuming the intention of the
RFC, or I'm missing something that I'd like you to clarify. Maybe you
can point out where our understanding diverges below:

If RRULE is FREQ=weekly, for ex, RFC2445 explains how to generate all
the recurring start times from the DTSTART in the event.

Agreed?

All start times will be in either the local time zone (no TZID on the
DTSTART), or in the timezone specified in the DTSTART.  This is the
floating/non-floating difference.

Agreed?

If DURATION specifies each occurence is 1 day (or 5 hours, or whatever),
you add that duration to the 1st, 2nd, and later, occurence's start
time.  The end times, like the start times, are in the local timezone if
the TZID is not specified ("floating").

Agreed?

Of course, addition of the duration is sensitive to DST shifts, as well
as to leap years, etc. So, start=5AM + duration=5hours is not
necessarily end=10AM.

If the duration is 5 hours, it has to *be* 5 hours of elapsed time.

Or, is it possible where this is where we diverge? That you think this
isn't specified adequately or at all in RFC2445?

Cheers,
Sam

-- 
Sam Roberts <[email-masked]>

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 9 14:46:20 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050409/be3e6099/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 9 15:54:45 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050409/fd5a2e84/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Apr 9 17:16:05 2005

Am Sonntag, 10. April 2005 00:54 schrieb Doug Royer:
> OOPS - I did not cut out all of what I sent - sorry, I did
> NOT mean to imply that sam said that!!
>
> I say and I ask:
>
>
> Start off with:
>
>    DTSTART:20050402T150000          2-APR-2005 3pm
>    DTEND:20050403T180000            3-APR-2005 6pm
>
> Now add 2-APR-2006 and with a time:
>
>    RDATE:20060402T154500
>
> Notice that the RDATE value starts 45 minutes after the 1st instance.
>
> So at what time does the 2nd instance end ?

45 minutes after the 1st instance ended. (Take the rdate and simply add the 
difference between dtend and dtstart to it).
Why should it make a difference that the first occurence hasn't yet ended? 

E.g. image the planning (or the publication) of museum tours. If you have more 
than one tour guides, the second tour can alreaday start before the first one 
ended. All tours will provide the same information, and the name of the guide 
shouldn't be in the published information at all, so you can just create one 
event and let it recur at whatever times the tours start.

Cheers,
Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050410/383ae736/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 9 18:51:29 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050409/75590f7c/smime-0001.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Sat Apr 9 18:59:57 2005

Hi Reinhold,

--On Sunday, April 10, 2005 02:15:52 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> 45 minutes after the 1st instance ended. (Take the rdate and simply add
> the  difference between dtend and dtstart to it).

No - you are missing the point. Lets explain this again a little 
differently:

Consider an event that occurs twice between the hours of 12 am and 8 am 
local time (EST is used in my example). It occurs on two consecutive 
Sundays. One of those Sundays involves a daylight savings change. So:

Instance 1 (this is the one where DST changes):

DTSTART;TZID=US/Eastern:20050403000000
DTEND;TZID=US/Eastern:20050403080000

Instance 2:

RDATE;TZID=US/Eastern:20050410000000

Note that in instance 1 the clocks go forward an hour at 2 am. So the 
duration of the event is actually 7 hours as opposed to 8 hours. Using your 
algorithm ("Take the rdate and simply add the  difference between dtend and 
dtstart to it") would result in the second instance ending at 7 am. Is that 
what was intended or should it end at 8 am? i.e. is the local end time 
supposed to be fixed or is the duration supposed to be fixed? You would 
have a similar problem if DURATION was used instead of DTEND.

The issue is that right now clients have to infer the end time of 
recurrence instances (after the first one) in some unspecified manner (2445 
does not really explain), unless an RDATE with PERIOD values is used (the 
period explicitly gives both the start and the end).

i.e. to remove any ambiguity the second instance could have been specified 
as:

RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410080000

    (always end at 8 am local time)

or:

RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410070000

    (always run for 7 hours)

depending on what was actually wanted.

-- 
Cyrus Daboo

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 9 19:22:14 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050409/74959308/smime.bin

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Sat Apr 9 20:14:39 2005

On Saturday, April 9 2005, "Doug Royer" wrote to "[email-masked]" saying:

> In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART
> as the way to process RDATE and any 2445 RRULE found. It ~looks~
> to me as if that is how most implementations did it.

That's certainly the simpler way to do it, and possibly the best-defined
way.

However, I don't think it satisfies the principle of least astonishment.  If
a work shift always goes from midnight to eight a.m., the usual cultural
convention is that you have a seven hour shift on the clocks-forward day, and
a nine hour shift on the clocks-backward day.

I think a more intuitive resolution rule is as follows:

1. If the RDATE or RRULE instance falls at a different time of day than
   DTSTART, DURATION = DTEND - DTSTART always.

2. However, if an RDATE or instance of an RRULE falls at the same time of
   day (in the relevant time zone, ignoring offset shifts) as DTSTART, then
   the end of the recurrance instance falls at the same time of day as
   DTEND, even if this would mean that the event has greater or lesser
   duration.

3. If the DTEND computed by rule 2 above doesn't exist (because it would
   fall during a clocks-forward period), or if it is ambiguous (because the
   time is repeated during a clocks-back period), fall back to rule 1.  For
   clocks-back, this should always have DTEND being one of the repeated
   times; for clocks-forward, the end time in the new offset should be
   equivalent to the "proper" end time in the old offset.  (Both of these
   conclusions assume sane DST rules, e.g. you don't have multiple
   transitions in a single 24-hour period.)

The only surprising behavior with this rule would be when you have a rule
whose base DTSTART-DTEND period spans an offset shift, *and* some RDATEs or
RRULE instances fall at different times of day than DTSTART.

This definition is more complicated, but I think it reflects human
expectations better.  The counter-argument for Calsify of "it's not how
existing clients do it" is a strong one, though.

Either way, these semantics needs to be made explicit in whatever becomes
the updated definition of recurring events.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Apr 9 22:03:50 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050409/4d8487cf/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 10 06:43:03 2005

> Sam Roberts wrote:

Doug,

this is a DTSTART/DTEND style example. You have said, unless I
completely misunderstand, that even DTSTART/DURATION style
specifications have a problem, perhaps even the same problem, and that
it has something to do with floating times.

This is what I haven't seen an example of.

Thanks,
Sam

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sun Apr 10 10:16:29 2005

Am Sonntag, 10. April 2005 03:59 schrieben Sie:
> Sundays. One of those Sundays involves a daylight savings change. 

Ah, sorry. I didn't know that US/Eastern time switches to DST in April. 
Everywhere here in Europe the DST changes occur on the last sunday in march 
and the last sunday in October.

Basically, your problem just makes it clear what I meant by "But then, I'm not 
sure if there is really a unique way to calculate the DTEND 
without using the duration..." in my mail on April 3 
(http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000483.html).

Actually, as long as the frequency is >= daily in an RRULE (without a BYHOUR 
or BYMINUTE value), or no new time is given in an RDATE, the end time can be 
taken from the original DTEND. But as soon as the start time changes compared 
to the first occurence, you're out of luck.

The same problem happens with the date and leap years. And there it happens 
even without strange things like an RDATE with explicit time. Just take 
weekly recurrence rules. How will you ever correctly calculate the end date, 
since you only have the n-th day of the month available from the DTEND. But 
since you are using weekly recurrence, the only information that you have 
available is the duration.

E.g. take the event 
DTSTART;VALUE=DATE:20040206
DTEND;VALUE=DATE:20040211
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=FR

The occurences will be 
-) Feb 6 - 10, 2004
-) Feb 13 - 17, 2004
-) Feb 20 - 24, 2004

And the next one creates the problems: It will be Feb 27 - March 2, 2004, 
right (where you use the duration to calculate the end date)? The only 
information that you can use here is the duration.

So, only in some cases is it possible to use the real end date to obtain more 
information. In some cases only the duration is available. the question now 
is whether the standard should just use duration-based end date / times , or 
whether it should be smart and describe when it's possible to use more 
information about the end date/time and when one needs to use the duration. 
My guess is that the latter is quite tricky to get right and water-proof.

Now take a monthly event:
RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=27
DTSTART;VALUE=DATE:20040127
DTEND;VALUE=DATE:20040203

If you want to take the end date from the DTEND (which is basically what is 
suggested on calsify), you'll have the following events:

-) Jan 27 - Feb 2, 2004 (7 days)
-) Feb 27 - March 2, 2004 (5 days)
-) March 27 - April 2, 2004 (7 days)
-) April 27 - May 2, 2004 (6 days)

Okay, so this event has a varying duration. Now imagine an additional
RDATE;VALUE=DATE:20040225

When will this occurence end? The only information that you have now available 
is the duration.

So, this problem is not restricted to RDATEs that give a different start time 
than the first occurence, but it also happens with date-only events.

Cheers,
Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050410/aac69b58/attachment.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 10 18:24:42 2005

Quoting [email-masked], on Sat, Apr 09, 2005 at 08:22:01PM -0600:
> Cyrus Daboo wrote:
> >recurrence instances (after the first one) in some unspecified manner 
> >(2445 does not really explain), unless an RDATE with PERIOD values is 
> >used (the period explicitly gives both the start and the end).
> >
> >i.e. to remove any ambiguity the second instance could have been 
> >specified as:
> >
> or
>   RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT8H
> 
> or
> 
>   RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT7H
> 
> So, I think this means that RRULE is busted as it can
> not fix the above problem.

What do you mean by "RRULE is busted"? That example doesn't even have an
RRULE in it. If you always want a fixed duration:

  DURATION:+PT7H
  RRULE:FREQ=weekly

Whats "busted"?

> And in CALSIFY I am proposing that we say you MUST use
> RDATE/PERIOD because RDATE/DATE, RDATE/DATE-TIME and RRULE
> are busted in such cases.

Busted in which cases? The specific case of wanting fixed-end events as
opposed to fixed-duration?

Sam

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Sun Apr 10 18:50:29 2005

> That's certainly the simpler way to do it, and possibly the best-defined

But even saying DURATION = DTEND - DTSTART isn't sufficient.

We need to specify how the subtraction is done when DTEND and DTSTART
straddle a time shift, and warn implementors to consider the issue I
think that the DURATION should be in *absolute* time. I.e., 10AM - 5AM
is 5 hours only if there really are 5 hours between them, and not 4 or 6
hours (for example).

This is easy to implement, since you can take DTSTART and DTEND and
convert them to an absolute time scale, such as UTC, then do the
subtraction there. You can do addition in UTC as well.

I'm not suggesting this as some kind of a normative requirement, just
that it is easy to calculate offsets with absolute durations if you can
convert between localtime and UTC - and if you can't do that you'll be
in trouble.

Cheers,
Sam

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Sun Apr 10 19:56:50 2005

> convert between localtime and UTC - and if you can't do that you'll be

I think this *should* be a normative requirement; it's clearly the only
meaningful semantic for date-times with time zone references.

Now, how this should be interpreted for floating date-times is another
question.

There's also the question of "does 1 day equal 24 hours", which was the
subject of a long thread on the ietf-calendar list (I think).  Which is to
say, when does an event with DTSTART;TZID=America/New_York:20050403T000000
and DURATION:P1D end?  (Note to non-US readers: Sunday April 3 2005 was this
year's leap-forward date; 24 hours after 2005-04-03 00:00:00 EST is
2005-04-04 01:00:00 EDT.)

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 10 20:14:43 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050410/8305a5c6/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Apr 10 20:31:33 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050410/e4cb2055/smime-0001.bin

---

From: martijn at eekeek.org (Martijn van Beers)
Date: Mon Apr 11 09:37:31 2005

On Sun, 2005-04-10 at 21:31 -0600, Doug Royer wrote:
> Good point. We decided against 'M' (month) in PERIOD because it has
> a variable length
> 
> We could eliminate 'W' and 'D' as they can get confusing for that
> reason.

Then you'd have to eliminate minute and hour too, since leap seconds
make them variable length too.

Martijn

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 10:18:08 2005

> We could eliminate 'W' and 'D' as they can get confusing for that

Isn't that exactly why you do need them? Without them, i don't see how 
you set a duration of 1 day. Using 24 hours won't do, because 1 day 
might be 25 hours. A duration of 1 day would mean: until the same time 
the next day.

Michiel

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Apr 11 10:46:57 2005

> might be 25 hours. A duration of 1 day would mean: until the same time 

What does DURATION:P1DT8H mean, then?

Also, since this is calsify -- how do existing clients handle day-based
durations (with or without hours) which cross an offset change?

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 11:40:32 2005

> What does DURATION:P1DT8H mean, then?

A duration of 1 day, 8 hours. So first add one day (23, 24 or 25 hours), 
then add another 8 hours.

> durations (with or without hours) which cross an offset change?

This discussion has gone a long way from looking at what existing 
clients do anyway, with all kind of suggestions for forbidding things 
and about what certain things should mean etc. So i just added another 
suggestion :)

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 11:52:22 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/e648ae3b/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 12:08:16 2005

Doug Royer wrote:
> The problem is defining how to uses them so that all ends have
> the results when they display to a CU. Its
> 
Can hou give an example of a rule that is ambigious? Or is you remark 
based on experience with existing clients? if so, can you give an example?

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 12:13:55 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/e98551bf/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 12:23:35 2005

Doug Royer wrote:
> Martijn did today on this list - leap seconds.

Yes, and that is why i think you need to be able to say that an event 
lasts 1hour. The amount of seconds in that hour might differ, just like 
the amount of hours in a day. But for the user, it is still an hour, or 
a day.
So i stil don't see why the different length of a day is a problem.
If you remove the ability to express a day from duration, and at the 
same time duration is the solution to the dtend problem, you just can no 
longer express an event that just takes 8 hours, no matter if there is 
daylight saving.

Michiel

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Apr 11 13:14:22 2005

> the results when they display to a CU. Its

We could certainly define semantics for time-unit arithmetic -- the basics
aren't very hard, though the corner cases are tricky -- but I'd really
rather know what existing systems actually do first, so we don't go too far
off into the weeds defining weird semantics.

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Apr 11 13:36:36 2005

> off into the weeds defining weird semantics.

(Following up to myself...)

Indeed, do any current CUs handle leap seconds at all?  If they don't, I'd
be strongly tempted to forbid leap second handling in iCalendar at all.

Relevant corner case events whose end times I'd like to nail down
(1998-12-31 23:59:60 UTC was the most recent leap second):

A)
DTSTART:19981231T235900Z
DURATION:PT1M

B)
DTSTART:19981231T235900Z
DURATION:PT2M

C)
DTSTART:19981231T230000Z
DURATION:PT2H

D) [this is the tricky one]
DTSTART:19981231T235960Z
DURATION:PT1M

And the equivalent cases for both date-time with TZID and for floating times
(for a local time corresponding to midnight UTC).

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 13:43:56 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/4f5f2c20/smime-0001.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 13:44:28 2005

> be strongly tempted to forbid leap second handling in iCalendar at all.

What would be the expected result if the CU handles leap seconds? And 
what if it doesnt?
(Note that if it just splits into hours, minutes, seconds etc, and then 
adds to the minute, it might looks like it handled leapseconds, while in 
fact it didn't. or the other way around.)

Michiel

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Apr 11 13:47:34 2005

> What would be the expected result if the CU handles leap seconds? And 

That's the question -- I don't know.  RFC 2445 is silent on this.

> fact it didn't. or the other way around.)

Indeed.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 14:04:37 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/9d5ad4a5/smime.bin

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 14:07:04 2005

Doug Royer wrote:
> Most ignore all time zone shifts. As in:
> 
>     1D always == 86400S
>     1W always == 604800S

I checked the source of libical (which at least mozilla calendar uses, 
and afaik evolution uses it too), and it indeed does that.

Michiel

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Apr 11 14:28:42 2005

Am Montag, 11. April 2005 22:43 schrieb Doug Royer:
> Jonathan Lennox wrote:
> > We could certainly define semantics for time-unit arithmetic -- the
> > basics aren't very hard, though the corner cases are tricky -- but I'd
> > really rather know what existing systems actually do first, so we don't
> > go too far off into the weeds defining weird semantics.
>

In KOrganizer its "1D always means: Increase the date by one, leave the time 
untouched.".

> I would be happy if we just specified that in CALSIFY.

No, that completely defeats the purpose of having D and W durations. D means 
"Add one day to the date", W means "add 7 days to the date" (even if one of 
these days is longer/shorter than 86400 seconds).

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/506cf097/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Apr 11 14:31:04 2005

Am Montag, 11. April 2005 22:42 schrieb Michiel van Leeuwen:
> Jonathan Lennox wrote:
> > Indeed, do any current CUs handle leap seconds at all?  If they don't,
> > I'd be strongly tempted to forbid leap second handling in iCalendar at
> > all.
> >
> > A)
> > DTSTART:19981231T235900Z
> > DURATION:PT1M
>

Since in leap seconds the 59th minute has 60 seconds, in both cases the DTEND 
would be 19990101T000000Z (since 1M should mean: just add 1 to the minutes 
count, leave the seconds untouched).

> fact it didn't. or the other way around.)

I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to the 
minutes" (even if the minute doesn't have exactly 60 seconds).

Cheers,
Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/92f5117a/attachment.bin

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Apr 11 14:44:54 2005

> minutes" (even if the minute doesn't have exactly 60 seconds).

Given that, how would you handle my case D?

DTSTART:19981231T235960Z
DURATION:PT1M

"Add one to the minutes, leave the seconds alone" would imply an end time of
1999-01-01 00:00:60 UTC, but there is no such time.

This is nit-picky for leap seconds, which nobody really handles anyway, but
it's important for daylight saving time shifts.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 15:03:36 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/696d64ee/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Apr 11 15:08:12 2005

Am Montag, 11. April 2005 23:44 schrieb Jonathan Lennox:
> > Since in leap seconds the 59th minute has 60 seconds, in both cases the
> > DTEND would be 19990101T000000Z (since 1M should mean: just add 1 to the
> > minutes count, leave the seconds untouched).
> >
> > > adds to the minute, it might looks like it handled leapseconds, while
> > > in fact it didn't. or the other way around.)
> >
> > I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to
> > the minutes" (even if the minute doesn't have exactly 60 seconds).
>
> "Add one to the minutes, leave the seconds alone" would imply an end time
> of 1999-01-01 00:00:60 UTC, but there is no such time.

Intuitively I'd say 00:00:59 (i.e. the last second of the minute). Of course, 
that can't be deduced from any standard, but that's what I as a user would 
expect. Of course, for me as a programmer it would be simpler to just 
understand 1M as 60 seconds, but I doubt that this is what a user would 
expect.

> it's important for daylight saving time shifts.

Exactly, you run into the same problems. In particular, take (March 27, 2005, 
is the date when summer time was introduced everywhere in the EU):
DTSTART;TZID="Europe/Vienna":20050326T023000
DURATION:P1DT
Since the hour from 02:00 to 03:00 is skipped, there is no 02:30 on March 
27.... I'd say, the event should end at the last valid time before that time. 
That would mean it would end a 02:00. 

Actually this would make sense insofar as before 02:00 the event was still 
going on. Then the time jumps to 03:00, and then the event is not going on 
any more according to the calculation without time jump.

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Mon Apr 11 15:20:48 2005

Doug Royer wrote:
> Lets deprecate all but 'S' so that everyone can
> use the same calculation method and keep the
> most compatibility with existing CUA's.

How would you express an event lasting 1 day in this suggested way? (1 
day meaning just add 1 to the day, don't touch time) Which is the 
situation where dtend is problematic, and what duration was supposed to 
be a solution for. But if you can't use duration either, there is a 
problem...

Michiel

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Apr 11 15:28:27 2005

Am Dienstag, 12. April 2005 00:03 schrieb Doug Royer:
> This seems to be the same argument how to find the correct
> end time. If the argument is that is all the Attendee CUA
> has to do is add to DATE (not time), then why can't the
> Organizer CUA do that and send out everything in seconds?

Because it makes a difference when you use RRULE or RDATE (and one of the 
occurences fall on the daylight shift). 

> Existing 2445 implementation would process ##S correctly
> as would CALSIFY implementations.

But that's usually not what users would exists. If I have an event at 13:00 
and it lasts 1 day, I expect it to end on 13:00 on the next day, no matter if 
the night is one hour shorter or longer as usual.

Even if the "big two" (as you put it) don't think like that, I would say 
that's a bug in their implementation. 

> use the same calculation method 

Hell, let's just get rid of all RRULE and RDATE (and the RECURRENCE-ID)! If 
each event is created separately with it's own DTSTART and DTEND, we won't 
have any problems </sarcasm> Just because we find some inconsistencies, 
doesn't mean it's best to simply remove that feature. That's throwing out the 
child with the bath.
I think it's more important to write down how to handle all these cases 
exactly (because that's what lead to the fragmentation: nothing in the spec 
said how to calculate the dtend). 

> Converting from 2445 DURATIONs:
>
> 	I think we could live with saying 1M == 60S.
>
> 	The big two vendor seem to say that 1D = 86400S.

Oh, great. Exchange also didn't use the minus sign in the alarms, so let's 
just disallow the minus in the alarm offset! </sarcasm> Just because one 
company chose one particular implemention (which in my eyes is not what is 
meant in rfc 2445), all others should be forced to use the same brain-dead 
implementation?
There are lots of places where Exchange is not really standard-compliant. Are 
you now trying to argue to adapt the standard to what Exchange implement? 
(And leave all other existing applications in the cold, when they try to get 
things right).

>         And lets say that 1W == 7D.

Yes, that's clear, because no weekdays are skipped or added, even in leap 
years.

Cheers,
Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/d97ffc64/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 16:09:40 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/85c96cfd/smime-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 16:15:33 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/c7dfdbaf/smime.bin

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Apr 11 18:51:34 2005

So, if I'm following this correctly, what we're saying is that the UI of 
any CUA can present whatever it wants, but when sending duration it should 
always use seconds. For example, I say a meeting occurs once per day and 
lasts one hour; but when one implementation sends it to another, the 
meeting occurs once every 86,400 seconds and lasts 3600 seconds. I still 
think there might be problems with time shifts under this method, unless 
the implementations calculate the correct number of seconds for leap years 
and centuries, and add leap seconds as appropriate, but this should in 
general work.

I don't see a real problem, however, with a definition that allows certain 
longer periods to be transferred (day, month, year especially) and which 
defines the addition to be done in the way most people expect - if I say 
something occurs monthly, add 1 to the month modulo 12; for daily use the 
"usual" date arithmentic allowing for the standard days per month and leap 
years.  Some of these periods and their associated addition algorithms are 
very well defined and probably implemented in similar if not identical ways.

At 07:09 PM 4/11/2005, you wrote:

>Michiel van Leeuwen wrote:
>>Doug Royer wrote:
>>
>>be a solution for. But if you can't use duration either, there is a problem...
>
>Send the duraiton in seconds.
>
>If The Organizer CUA hard code 1D = 86400S, then all Attendees
>will know how long of a time period is being talked about
>because it is in the duration in seconds.
>
>If they hard code 1D = 86400S +/- some time shift on rare
>occasions then they will send out ####s and all Attendees
>will know how long of a time period is being talked about
>because it is in the duration in seconds.
>
>The purpose of CALSIFY is to make things work between
>vendors. Eliminating things that are not portable (D, W,
>and M) and keeing things that are portable (S), makes
>it work for everyone.
>
> > But if you can't use duration either, there is a
> > problem...
>
>You can use duration, just not non-portable values.
>
>--
>

Tim Hare

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 19:11:20 2005

> it's important for daylight saving time shifts.

IIRC, even POSIX says that standard time is time without considering
leap seconds. A bit of a cop-out, but understandable - unlike leap years
leap seconds are added "every once in a while", theres some
international body that looks at the drift in the clock from the solar
year and issues corrections.

So, its possible to handle the past ones, but impossible to handle
future ones without some kind of real-time mechanism.

I hope I didn't butcher that description!

Anyhow, leap seconds are unpredictable, to my knowledge, but leap years,
DST, and the fact that months have different lengths is all known in
advance.

Cheers,
Sam

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 19:17:22 2005

> 27.... I'd say, the event should end at the last valid time before that time. 

I can see that, it needs clarification, though.

What do you do with a DTSTART of January 31st, set to recur
FREQ=monthly?

My interpretation of RFC2445 was that if running the RRULE results in a
non-existent time, the event doesn't happen. So, that particular rule
would only give occurences in months that have a 31st (you can always
use one of the BY* rules to select the last day of all months, if that
was what was intended).

Sam

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 19:22:29 2005

> Most ignore all time zone shifts. As in:

That surprises me, even the standard C library deals with time shifts
better than that! Are you just looking at windows?

If you use mktime to construct two times, they are handled internally as
UTC, so subtraction gives true duration in seconds. Ruby's Time class is
a pretty thing wrapper around the C APIs, so vPim deals with this just
fine.

Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 19:23:04 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/5f160fd1/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 19:30:09 2005

> Yes, that's clear, because no weekdays are skipped or added, even in leap 

But only if a day is really a day, and not 24 hours/24*60*60 secs!

Btw, my interpretation is like yours. When you add a year, you get the
same date and time, one year later irrespective of leap years.

When you add a day, you get the same time, one day later, irrespective
of DST shifts.

That was easy to implement. The only oddities are when I arrive at a
time that doesn't exist on a particular day.

Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 19:32:49 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/8ba77c31/smime.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 19:50:59 2005

Quoting [email-masked], on Mon, Apr 11, 2005 at 05:15:16PM -0600:
> Reinhold Kainhofer wrote:
> >But that's usually not what users would exists [expect?]. If I have an 
> >event
> > at 13:00  and it lasts 1 day, I expect it to end on 13:00 on the next 
> day,
> > no matter if the night is one hour shorter or longer as usual.
> 
> Then the Organizer CUA is free to do the math that way, as long as what 
> it sends out is not open to interpretation at least two different ways.
> 
> What's the point of CALSIFY?

To clarify points the have been interpreted differently due to
weaknesses in the spec.

To throw things away that noone has implemented interoperably. No
interoperable implementation means it can't be standardized, if I
understand IETF rules.

Thats my understanding, anyhow.

And that doesn't include things that are widely implemented fairly well,
like RRULE.

I did a clean room implementation, not having found any informative
source, and the other calendars I've seen do fine when interpreted by my
RRULE code. I publish all the birthdays in my address book to Apple's
iCal recurring events, and it worked fine. I've had one problem with a
RRULE, a misinterpretation by Apple, IMO, of an odd-ball provincial
holiday on the second monday of every August. I need to post about that.

Also, I've got 75 RRULE's in my local calendars, my calendars are
published to others, and many of those RRULEs are my friends work or
play schedules, and they have events that recur indefinitely every week.
Explicitly listing a twice-a-week event with RDATE would be an exercise
in pain!  Even Canada Day occurs every year.

The "RRULE doesn't work well story" just doesn't fit my experience.

But, I haven't implemented iTIP.  I have the impression RRULE doesn't
work so well in iTIP.

If there aren't any interoperable implementations of scheduling events
specified using RRULE, then maybe the iTIP profile needs to be amended
to state that all meetings use RDATE with explicit end times, or maybe
every event occurence as a single VEVENT.  If thats what the
implementors of scheduling programs think will make their job easier, I
could easily be convinced that was reasonable.

Cheers,
Sam

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Mon Apr 11 20:33:24 2005

Quoting [email-masked], on Mon, Apr 11, 2005 at 08:32:38PM -0600:
> >UTC, so subtraction gives true duration in seconds.
> 
> Because there is no time shift in UTC, and ignoring leap seconds.
> IT means that 1D always == 86400S and 1W always == 604800S

Exactly.

> Maybe most people use mktime ?

Likely, so most implementations with no special effort, using only POSIX
APIs, can deal with 1 day meaning 1 day in their timezone, so that your
statement that "most should ignore time zone shifts" really surprises
me.

> >Ruby's Time class is
> Try trying to get mktime to do the math on times that are not in
> the systems TZ :-)

I'm aware of that, and so I suspect that most systems work well only in
their local timezone and UTC.

I would not be suprised by a statement of "most don't know how to deal
with timezones other than theirs and UTC".

Its hard to deal with non-local timezones, but I don't think they can be
removed. Timezones exist, you have to deal with them, and not all events
are fixed in UTC. Meetings are, thats true, but if the Vatican published
a calendar of expected times for sunday mass, would they have to publish
one for each timezone, with all times in UTC?

Has anybody implemented date-time arithmetic in timezones other than
localtime and UTC well? I'd like to hear how they did it.

Cheers,
Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 20:42:14 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/15b50120/smime-0001.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Apr 11 20:46:57 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050411/eea9e769/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Apr 12 02:16:00 2005

On Tuesday 12 April 2005 04:16, Sam Roberts wrote:
> > > On Monday, April 11 2005, "Reinhold Kainhofer" wrote to
> >
> > "[email-masked]" saying:
> > Exactly, you run into the same problems. In particular, take (March 27,
> > 2005, is the date when summer time was introduced everywhere in the EU):
> would only give occurences in months that have a 31st 

Yes, but these are different problems. With RRULE the problem is that the 
event might not happen at all. With duration the problem is that the start 
date/time exists, so the event does happen. The problem is when it ends.

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/f2c3d477/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Apr 12 02:24:28 2005

> very well defined and probably implemented in similar if not identical

Yes, that's also my view. We only need to write down these well-defined cases 
so that everyone can implement them exactly the same way.

Thinking of it, the duration (with intervals >S) is yet another case where the 
TZ information is actually needed, since depending on the TZ a day might have 
23, 24 or 25 hours. On the other hand, if you give the duration in S, you'll 
need the time zone to determine if a duration of 82800S meant really 23 
hours, or actually a day which due to the time zone shift has only 23 hours. 

This may not sound important, but if you try to move the event a day back, you 
need exactly this information to determine the end date/time. E.g. take an 
event at 14:00 on March 26 (in the EU summer time started on March 27, 2005) 
lasting 82800S. It will end on March 27, 14:00. Now move it to March 25. Will 
it end on March 26, 14:00 (i.e. duration is one day), or shall it end at 
13:00 (duration is 23 hours)? 
Usually, the first is what people would expect, but to recover the information 
that the duration is really one day you need to know that the event was 
planned in a time zone where the shift happens while the event takes place.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/94e58ba7/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Apr 12 02:25:08 2005

> it sends out is not open to interpretation at least two different ways.

But in that case you loose the meta-information that the event is supposed to 
last one day. It's the same problem as with removing RRULEs. Sure, the 
resulting events will look the same, but you loose the meta-information of 
what the organizer actually intended. And that's not what I call 
interoperability.

As I already said, I see the purpose of a standard to clearly define how 
things are supposed to be handled in all cases. So let's clearly state what 
1D means, and all standards-compliant applications will then understand it 
the same way.

> What's the point of CALSIFY?

To force the mistakes of a few implementations on all others?

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/c8052f20/attachment.bin

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Tue Apr 12 05:58:13 2005

> localtime and UTC well? I'd like to hear how they did it.

I have -- I modified the Olson TZ code to take a timezone argument.  I can
send a patch if people are interested.  (Markus Kuhn has a version of my
patch against an old version of the Olson code up at
<http://www.cl.cam.ac.uk/~mgk25/time/c/proposal-lennox.patch>.)

Java's java.util.Calendar class can also take a java.util.TimeZone class as
an argument to its constructor.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Apr 12 11:57:09 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/3cf7c3fc/smime-0001.bin

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Tue Apr 12 15:20:58 2005

> date/time exists, so the event does happen. The problem is when it ends.

I know, my mind was wandering onto other subjects, sorry!

Sam

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Tue Apr 12 15:24:08 2005

Quoting [email-masked], on Mon, Apr 11, 2005 at 09:46:46PM -0600:
> RRULE is one of the most busted features of iCal. I know
> of several valid iCal files I can send to various vendors
> that will cause them to crash, display totally bogus information,
> or completely ignore many of the instances.
> 
> I do not own the files or I would send them out.

dates and times are still in the public domain, you should be able to
send the DTSTART and RRULE values, theres no personally identifying
information in them.

They'd make nice test cases of the more extreme RRULEs.

Cheers,
Sam

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Apr 12 19:47:13 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050412/15ea1bea/smime.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Tue Apr 12 21:00:52 2005

Hi Sam,

> When you add a day, you get the same time, one day later, irrespective

OK, what about 2:30 am on the Sunday of a DST shift that adds one hour? 
That time does not literally exist as the clocks jump from 2 am to 3 am. So 
if you have 2.30 am on Saturday the day before, you can't simply add one 
day and expect to get a valid date-time. i.e. DST shifts do have to be 
taken into account for at least this edge case.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Apr 13 01:51:19 2005

On Wednesday 13 April 2005 04:47, Doug Royer wrote:
> Seems to me that as only the Organizer can move it back or change
> the dates. This is Organizer CUA-specific data - correct ?
>
> I mean if an Attendee changes the date / length, then we are not
> talking iCal or iTIP.

Ahm, I thought calsify was not only about sending out invitations, but also 
about general data exchange. E.g. drag'n'dropping an event from KOrganizer to 
evolution (or outlook to lotus). 

Also, what about counter-proposals? There you have exactly that situation 
where the attendee modifies/moves the event and sends back his new event. 

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050413/7393243b/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Apr 13 01:53:07 2005

> taken into account for at least this edge case.

As I wrote in a previous mail, I think it would be consistent and logical to 
define that the event ends on the last valid time before that invalid (i.e. 
not-happening) time.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050413/eed0bef1/attachment.bin

---

From: bruce at callenish.com (Bruce Atherton)
Date: Wed Apr 13 11:51:58 2005

>>>a pretty thing wrapper around the C APIs, so vPim deals with this just
Another data point is the Java Calendar class and the more specific 
GregorianCalendar class, used by almost all Java applications concerned 
with dates and times, including the ical4j library. Times are broken 
down into their component elements and arithmetic performed on that.

This means that adding is done primarily as your intuition would 
suspect. Adding 1 month to January 31 results in February 28th or 29th, 
while adding 3 months results in April 30th. Add a day and it is the 
next day at the same time, even over a time shift. If the resulting 
field is invalid, it is adjusted.

Adding a day to 20050402T0230 with timezone "America/Vancouver" results 
in 20050403T0130. Whereas adding a day to 20050402T0330 results in 
20050402T0330.

>localtime and UTC well? I'd like to hear how they did it.
This is something I've never understood about the iCalendar standard. 
Why isn't timezone primarily a presentation issue? If every date in 
iCalendar were stored in UTC, many problems go away. Then the CUA can 
render the event according to whatever the CU wants to see.

There are two exceptions I can think of to this. RRULEs/EXRULES need a 
timezone attached, but only to indicate when the UTC rendering should 
shift due to DST issues. And, to handle the "floating" type, there 
should be allowance in the standard for a hint to the CUA not to resolve 
the time according to a timezone, whether coming in or going out of 
iCalendar. Otherwise, I don't see what business timezones ever had in 
the standard.

I've only recently joined the list, so apologies if this point of view 
has been previously hammered upon.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Apr 14 01:15:05 2005

On Wednesday 13 April 2005 20:51, Bruce Atherton wrote:
> shift due to DST issues. 

No, not only for DST shifts. You need it e.g. for events that recur at 00:30 
every sunday (in central european time). In UTC this would be 23:30 on 
saturday, so the weekday of the recurrence rule heavily depends on the time 
zone.

Similarily, an event at 00:30 at every first of each month in CET (or CEST). 
In UTC this is 23:30 at every last of each month.

In these two examples the RRULE can theoretically be adjusted to UTC. 

But take e.g. 0:30 on ever first monday of each month. In UTC ths would be 
23:30 on sunday, but not necessarily on each first sunday. If the 1st falls 
on a monday the event would recur on the last day of the previous month. This 
RRULE cannot be transferred to UTC at all.

Cheers,
Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050414/935c4ad6/attachment.bin

---

From: bruce at callenish.com (Bruce Atherton)
Date: Thu Apr 14 11:30:05 2005

>RRULE cannot be transferred to UTC at all.
You make a good point that the definition of when an event is on a 
particular weekday defined in an RRULE depends on the timezone, but that 
just reemphasizes that RRULE needs a timezone. We are in agreement there.

But I don't see why you think the first Monday of the month can't be 
done with UTC. It may be due to my ignorance, but I don't understand 
your point.

In your example, your RRULE would have a timezone of CET, a frequency of 
monthly, and a ByDay of +1MO. The DTSTART would have a time of 233000 on 
the previous day. If you look at it with the CET timezone, the CUA would 
adjust the time to 013000 of the next day, check that the date equates 
to Monday in the CET timezone, and you are good to go. If you look at 
the same occurrence in the PST8PDT timezone, it becomes 153000 and stays 
on the previous day (Sunday). This gets checked to see if the same date 
and time equates to Monday in the CET timezone. It is, and again 
everything works out.

What am I missing?

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Apr 15 01:32:18 2005

> and time equates to Monday in the CET timezone. It is, and again

Yes, but how do you calculate that occurence? You can only do that correctly 
in the original time zone of the RRULE. 

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050415/1985f717/attachment.bin

---

From: bruce at callenish.com (Bruce Atherton)
Date: Fri Apr 15 08:29:13 2005

>in the original time zone of the RRULE.
But we agree that you have to have the time zone of the RRULE for a 
couple of reasons. So what is the problem in calculating the occurrence 
using that?