Re: Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)
Sam Roberts <sroberts <at> uniserve.com>
2005-04-03 15:25:14 GMT
Quoting Doug <at> royer.com, on Sun, Apr 03, 2005 at 01:02:48AM -0700:
> 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.
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.
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
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.
> 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.
> >Your choice to prefer duration over dtend appears based on the assumption
> >they can represent the same information.
> 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
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
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
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
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.
> I still think so, again perhaps not in exactly one object.
> 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.