Recurring events with timezone

Hendrik Helwich h.helwich at tarent.de
Wed Oct 27 14:25:17 CEST 2010



Am Mittwoch, 27 Oktober 2010 13:57:01 schrieb Andrew McMillan:
> On Wed, 2010-10-27 at 11:27 +0200, Joon Radley wrote:
> > > Still: 4:00am is easier than the 3:00am that it was a month ago, before
> > > my DST kicked in here in New Zealand, but I'm looking forward to US DST
> > > ending on November 7th after which the event will happens at 5:00am in
> > > my timezone.
> >
> > Again a view issue. The only time anchor time zone becomes relevant is
> > when an event is modified and must be anchored to a specific offset to
> > the original time zone.
>
> Oh, I did not realise that Kolab was storing every instance of an event.
> I assumed it was only storing an anchor point and calculating the repeat
> instances, as other calendar software tends to do.

Hi Andrew,

it is not possible to store every instance of an event in one kolab instance. 
The kolab event format structure is mostly similar to the iCalendar format 
structure. E.g. recurrence is described here:

http://kolab.org/doc/kolabformat-2.0rc7-html/x217.html

You are right this could also solve the problem but like you wrote, infinite 
recurring events will not be possible and interoperability with other 
calendar formats will be very bad.

Best regards,

Hendrik

> Certainly: if each future instance of an event is calculated when it is
> stored then of course you can reduce exposure to timezone issues by
> storing the calculated instant in UTC and localising it for display when
> needed.
>
> All of these problems we have been describing would only apply to
> repeating events where the time of only the first instance is stored,
> such as when I have an event scheduled for "Tuesday the 10th August 2010
> at 11:00am according the local time in New York, and on each subsequent
> Tuesday at 11:00am according the local time in New York".
>
> With the instances expanded when the event is stored, such a case will
> of course store the correct UTC time for the event as 3:00pm, for each
> Tuesday from 10th August through to 2nd November, and then will store
> the UTC time for the event as 4:00pm for each Tuesday from 9th November
> through to 8th March, and so on.  Then, knowing the DST rules for New
> Zealand, it becomes easy to localise these to my own timezone in order
> to know when I will need to wake up!
>
> If Kolab takes this approach, then it must still limit the recurrence
> instances calculated or it would use infinite resources!  So surely the
> problem will still bite when further instances are calculated?
>
> > > For my example above it doesn't change the event at all.  The event
> > > happens according to a time in the America/New_York timezone,
> > > regardless of my own location, or how long I am there.
> >
> > Even if you now live in New Zealand? I know it does not matter because
> > the view is adjusted for your new locale, but what is the purpose of
> > having the time zone in the model then?
>
> Sure, I live in New Zealand, but the teleconference is scheduled
> according to a New York time, where other parties on the conference call
> live, rather than where I live.
>
> Other people on the call live in Europe, some in South America, a few in
> Australia, but we had to pick *some* timezone and the boss lives in New
> York and he likes to fit the meeting in between his regular lunch
> appointment and his regular Tuesday 10:30 meeting with the finance
> committee.
>
> Cheers,
> 					Andrew.




More information about the format mailing list