Mailing List Archive

On Thu, 2010-11-18 at 10:36 +0100, Matthias Althaus wrote:
> Hey there,
>
> I stumbled upon a new issue and don't know if it's my fault or a bug in Davical. :)
>
> I'm now using the expanded REPORT to fetch the events to show including the expanded RRULEs. Davical does this fine, but
>
> a) All dates are in UTC, but no timezone information is given.

The specification for event expansion specifies this.


> b) DTEND gets replace with DURATION. Got around this by recalculating DTEND.

In expanding the RRULE I found it easier to use DURATION than DTEND, and
to do so is within specification, so... :-)


> c) Allday events get a time.
>
> DTSTART;TZID=Europe/Berlin:20101111T100000
> DTEND;TZID=Europe/Berlin:20101111T110000
>
> becomes
>
> DTSTART;20101111T090000Z
> DURATION;PT60M
>
> which is fine except that the TZID is lost completly. At the moment FC
> shows the dates correct (although I don't know yet why... something
> like using local TZ).

Well... Since expanded events *must* be reported as UTC, the start time
of the date is necessarily encoded as part of the expansion. The
example above is not an all day event though


> c) is now a serious problem:
>
> DTSTART;VALUE=DATE;20101111
> DTEND;VALUE=DATE;20101112
>
> becomes
> DTSTART;20101111T010000Z
> DURATION;P1D (acutally Davical returns minutes, but that doesn't matter)
>
> Now I cannot know anymore that is was allday. Due to the offset shift
> I cannot say that T000000Z to T000000Z of another day is allday.
>
> Without expanding this was easy: no time value => allday

Without expanding this you only *thought* this was easy. Without
expanding it you didn't see how other calendars *might* create events.
While it is true that 'no time value => all day', there is nothing in
the iCalendar spec which says 'time value => not all day', so you were
always going to have to deal with events in this way because people
using a calendar server might not all be using your web client.

Really, you have to look at an event and if the start time == the start
time for the day in the user's timezone, and the duration == 1 day =>
it's an all day event.

Really, that's the only way to successfully identify an all day event.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Flexibility is overrated. Constraints are liberating.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101119/7ad433b4/attachment.pgp>

Heyas!

> > a) All dates are in UTC, but no timezone information is given.
>
> The specification for event expansion specifies this.
Ok. So I def have to go with the users' local tz... :|

> > b) DTEND gets replace with DURATION. Got around this by recalculating DTEND.
>
> In expanding the RRULE I found it easier to use DURATION than DTEND, and
> to do so is within specification, so... :-)
Yeah... no problem for me as it's quite easy to get DTEND back. :D

> > c) Allday events get a time.
> >
> > DTSTART;TZID=Europe/Berlin:20101111T100000
> > DTEND;TZID=Europe/Berlin:20101111T110000
> >
> > becomes
> >
> > DTSTART;20101111T090000Z
> > DURATION;PT60M
> >
> > which is fine except that the TZID is lost completly. At the moment FC
> > shows the dates correct (although I don't know yet why... something
> > like using local TZ).
>
> Well... Since expanded events *must* be reported as UTC, the start time
> of the date is necessarily encoded as part of the expansion. The
> example above is not an all day event though
Sorry for the missleading markup... I didn't mean that *this* is allday... a) to c) was more a list thingy with c) following after this. Too much crosswriting between windows. ^^

> > c) is now a serious problem:
> >
> > DTSTART;VALUE=DATE;20101111
> > DTEND;VALUE=DATE;20101112
> >
> > becomes
> > DTSTART;20101111T010000Z
> > DURATION;P1D (acutally Davical returns minutes, but that doesn't matter)
> >
> > Now I cannot know anymore that is was allday. Due to the offset shift
> > I cannot say that T000000Z to T000000Z of another day is allday.
> >
> > Without expanding this was easy: no time value => allday
>
> Without expanding this you only *thought* this was easy. Without
-_-'

> expanding it you didn't see how other calendars *might* create events.
> While it is true that 'no time value => all day', there is nothing in
> the iCalendar spec which says 'time value => not all day', so you were
> always going to have to deal with events in this way because people
> using a calendar server might not all be using your web client.
Hmm... I start to dislike the vcalendar specs. :(

So there is nothing like a "floating all day thing"? Give a birthday for example... my birthday this year stated as VALUE=DATE;20100516 is quite clear and doesn't move between timezone... it's the same day here and in New Zealand... isn't it?

If I add it through Sunbird/Lightning it's send this way to the server. With expanding it becomes 20100516T010000Z... if I now share this event with you, it would become a 24 hour event from ~13 to 13 (?) as your tz is not +1 and therefore not recognized as allday?

> Really, you have to look at an event and if the start time == the start
> time for the day in the user's timezone, and the duration == 1 day =>
> it's an all day event.
I already feared that this is the only upcoming way... ;)

Thanks for sharing your time to clear up things!

Cheers
Matthias

On Fri, 2010-11-19 at 10:15 +0100, Matthias Althaus wrote:
> > > Without expanding this was easy: no time value => allday
> >
> > Without expanding this you only *thought* this was easy. Without
> -_-'
>
> > expanding it you didn't see how other calendars *might* create events.
> > While it is true that 'no time value => all day', there is nothing in
> > the iCalendar spec which says 'time value => not all day', so you were
> > always going to have to deal with events in this way because people
> > using a calendar server might not all be using your web client.
> Hmm... I start to dislike the vcalendar specs. :(
>
> So there is nothing like a "floating all day thing"? Give a birthday
> for example... my birthday this year stated as VALUE=DATE;20100516 is
> quite clear and doesn't move between timezone... it's the same day
> here and in New Zealand... isn't it?
>
> If I add it through Sunbird/Lightning it's send this way to the
> server. With expanding it becomes 20100516T010000Z... if I now share
> this event with you, it would become a 24 hour event from ~13 to 13
> (?) as your tz is not +1 and therefore not recognized as allday?

The purpose of expansion is supposed to be for display, so if you wanted
to modify a repeating event you would still have to request the original
and modify that. Of course if it's a repeating event then that gets all
complicated on it's own because you need to know whether you're
maintaining all instances, just this instance, or this and future
instances.

iCalendar can contain 'floating' time, where no timezone is specified
such as your birthday example, and it may well be that DAViCal is doing
the wrong thing with expansion in these cases. I'd really need to read
the spec again to be sure.


> > Really, you have to look at an event and if the start time == the start
> > time for the day in the user's timezone, and the duration == 1 day =>
> > it's an all day event.
> I already feared that this is the only upcoming way... ;)
>
> Thanks for sharing your time to clear up things!

No problem. It's stuff like this which tracks down barely tested corner
cases that don't normally show up for most people, and help me improve
my coverage.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Necessity is the mother of documentation
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101119/60d2770c/attachment.pgp>

> > If I add it through Sunbird/Lightning it's send this way to the
> > server. With expanding it becomes 20100516T010000Z... if I now share
> > this event with you, it would become a 24 hour event from ~13 to 13
> > (?) as your tz is not +1 and therefore not recognized as allday?
>
> The purpose of expansion is supposed to be for display, so if you wanted
> to modify a repeating event you would still have to request the original
> and modify that. Of course if it's a repeating event then that gets all
> complicated on it's own because you need to know whether you're
> maintaining all instances, just this instance, or this and future
> instances.
Yeah... for nothing else I'm using it. For updates I'm fetching the event freshly by UID. Changing single or multiple instances of a repeating event is something I don't want to think about yet... I know the usual three options... but... no... not yet. ;-)

> iCalendar can contain 'floating' time, where no timezone is specified
> such as your birthday example, and it may well be that DAViCal is doing
> the wrong thing with expansion in these cases. I'd really need to read
> the spec again to be sure.
I looked into the EXPAND spec and it clearly states that you're doing it correctly. :|

Cheers
Matthias