Recurring events with timezone

Andrew McMillan andrew at morphoss.com
Wed Oct 27 13:57:01 CEST 2010


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.

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.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
   Entropy requires no maintenance.
                -- Markoff Chaney
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.kolab.org/pipermail/format/attachments/20101028/f75ffc27/attachment.sig>


More information about the format mailing list