Recurring events with timezone

[Hendrik Helwich]

Am Mittwoch, 27 Oktober 2010 08:50:12 schrieb Joon Radley:
> Hi Georg,
>
> > I am curious: So how would you model the cases that have been given in
> > this thread as demonstration for why the timezone is
>
> The only model demonstrated that can not be solved by the client view was
> as follows:
>
> A recurring event where the event time is anchored to a specific user for a
> specific time zone. Anchored meaning that the time is always the same for
> the specific user regardless of day light savings time over the entire
> range of the recurrence.

Hi Georg,

i don't think this is a good idea. The recurring event should be anchored to a 
specific tz instead. This is the natural modeling and the tz depends on the 
location where the event should take place.
It is also less complex because you do not need to track the users timezone 
and do not need to change the event.
The user should have the freedom to decide in which tz the event should 
happen.

Best Regards,

Hendrik

> 1) This does not need the dropping of UTC for date time objects nor the
> introduction of a base time zone field. This will need a anchor/sticky
> field in the recurrence field. 
> 2) This is an edge case that I do not even 
> know that I can support in Outlook. Some research still needs to be done on
> this. If it is not supported in Outlook 2003 then it will not be possible
> for us to support this. 
> 3) Use cases for this model needs to be  clearly 
> defined. Three that stands out is: 3.1) when the anchored users travels
> into another time zone. Will the time stay the same for him/her or will it
> anchor to the time zone or will the time zone move to his/her new time
> zone? 3.2) when the user travels to a new time zone for an extended
> period(a month) does this now change the time zone to the new time zone?
> What happens if he/her modifies the object, do you use the new time zone,
> old time zone and under which conditions can the anchor time zone change in
> the object? 3.3) What happens if the user changes time zone permanently? Do
> you find all the objects in the store and modify them? 4) Formula used in
> calculations of day light savings time will have to be described in
> absolute detail for all time zones. Not all clients have the same locale
> functionality for all time zones and it does not help trying to address
> this issue without everyone using the same formula.
>
> 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 26 Oct 2010, at 6:45 PM, Georg C. F. Greve wrote:
> > Hi Shawn,
> >
> > On Tuesday 26 October 2010 18.35:45 Shawn Walker wrote:
> >> Personally, I don't think timezone in the kolab format should be needed.
> >
> > I am curious: So how would you model the cases that have been given in
> > this thread as demonstration for why the timezone is necessary?
> >
> > Right now I am not aware of a good response to them.
> >
> > Best regards,
> > Georg
> >
> >
> > --
> > Georg C. F. Greve
> > Chief Executive Officer
> >
> > Kolab Systems AG
> > Zürich, Switzerland
> >
> > e: greve at kolabsys.com
> > t: +41 78 904 43 33
> > w: http://kolabsys.com
> >
> > pgp: 86574ACA Georg C. F. Greve
> > _______________________________________________
> > Kolab-format mailing list
> > Kolab-format at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-format
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format