Recurring events with timezone

[Joon Radley]

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

Not what I said.

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

Again, if I am in South Africa, what do I care what time zone you scheduled it for, I just need to know what time of the night I need to get up for the call.

Best Regards

Joon Radley

Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at toltec.co.za
Web: www.toltec.co.za



On 27 Oct 2010, at 1:57 PM, Andrew McMillan wrote:

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