Recurring events with timezone

[Joon Radley]

Hi Hendrik,

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

In the case of a telephone conference what will be the location?

As a user not in your time zone, what do I care in which time zone this happens out of a model and not a view perspective.

> It is also less complex because you do not need to track the users timezone 
> and do not need to change the event.

But if the time zone is there to anchor a location what does it help when the user is not at the location?

> The user should have the freedom to decide in which tz the event should 
> happen.

The user has the freedom to _view_ the event in any time zone. It all happens at the same time regardless of time zone.

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 10:27 AM, Hendrik Helwich wrote:

> 
> 
> 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
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format