Recurring events with timezone

Wed Oct 27 11:59:33 CEST 2010

Am Mittwoch, 27 Oktober 2010 11:10:13 schrieb 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?

Hi Joon,

If there is no specified location you could use the UTC timezone. This is no 
problem if it is a single event. If this conference is a recurring event and 
should happen in the UTC tz then you could also do this right now and have no 
problem with the format. But some kolab clients (Kontact, Outlook/Toltec) do 
not calculate the UTC -> local mapping correctly. So in practice this would 
not work right now.
Right now if i create a recurring  event in Kontact or in Outlook with Toltec 
Connector like every month on the 27th day at 8 o'clock both clients show 
always the start time 8 o'clock even if the DST border is crossed. This shows 
that the calculation UTC -> local is not implemented correctly.

So it is not possible at the moment to create a recurring event which shows 
the correct times for people in different tzs even in UTC time.
If the clients would calculate UTC -> local correctly it would be possible to 
create such a recurring telephone conference at UTC time with the current 
kolab format.

But i think in practice you also often have the use case that the conference 
should happen at a local time in some fixed tz. This is not possible at the 
moment because of the design of the storage format.

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

you just need this tz information in the storage format in some use cases to 
calculate the correct UTC time.

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

Then you e.g. could use UTC tz. But the clients also must support that (see 
above)

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

this depends on what usecases should be covers i think. The correct 
calculation of the local time depending on the tz which is configured on the 
users system must be handled by the client application (probably with the 
help of an existing library).
If the discussed use case should be covered than you also need the tz 
information in the format and the user should be able to configure this.

Best Regards,

Hendrik

> 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

-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Treffen Sie uns auf der Messe Moderner Staat 2010 an unserem
Gemeinschaftsstand open source berlin vom 27.‒28.10.2010 in
Halle 2, Stand 310. Wir freuen uns auf Sie!

Heilsbachstraße 24,  53123 Bonn,   Telefon: +49 228 52675-0
Thiemannstraße 36 a, 12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/  • Telefax: +49 228 52675-25