Recurring events with timezone

Wed Oct 27 11:27:11 CEST 2010

Hi Andrew,

> Do you just mean:
> 
>        A recurring event specified as occurring in a particular
>        timezone other than the one the client is using for display.

No. All events happen at the same time regardless of time zone. It is just where you view it from.

Modify the model I have given so that we have an exact model. We need to work from concrete models else this will just be and endless debate about MVC.

> In iCal on a Mac it is certainly possible to anchor an event to a
> particular timezone.  Likewise it works fine in Evolution on Linux
> (whence this interoperation debate springs from), or emClient on
> Windows.

Please keep in mind that Outlook is a black box for the connector developers. We cannot introduce new behavior than that which is already provided by MAPI and the GUI.

> 
> For my example above, of the regular telephone conference, the time
> should always be anchored to the timezone in which the meeting time is
> defined.  At the moment I am some 17 hours ahead of America/New_York, so
> 11:00am Tuesday is a rather bleary-eyed 4:00am Wednesday for me but were
> I to fly to San Francisco over the weekend next week it would be a much
> more manageable 8:00am Tuesday in the America/Los_Angeles timezone.

You have travelled and your time zone and view has changed. How has UTC changed? There is no argument for having time zone information included.

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

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

> Rather, perhaps, don't even *attempt* to describe *any* formula for
> calculation of daylight savings times.  There are standard libraries for
> performing these calculations on every platform and language that I am
> familiar with (most use the Olson rules, in reality) and I feel it would
> be better not to overspecify in this area.

Have have developed on a lot of systems and OSes. Standards depend on interpretation. If everyone is not using the exact same method you will loose all the benefits you are trying to introduce.

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:44 AM, Andrew McMillan wrote:

> On Wed, 2010-10-27 at 08:50 +0200, Joon Radley wrote:
>> 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.
> 
> Do you just mean:
> 
>        A recurring event specified as occurring in a particular
>        timezone other than the one the client is using for display.
> 
> 
> The commonest real world example I have of this is the scheduling of
> conference calls, where the call time is often specified as something
> like "11:00am Tuesday in the America/New_York timezone".
> 
> In such a case if the time for repeat instances is calculated in my
> local timezone will be wrong when (a) I cross a DST boundary, and (b)
> the America/New_York timezone crosses a DST boundary.
> 
> If we have retained the information that the event is anchored to
> America/New_York then future instances can be calculated according to
> that timezone and each one can be converted correctly to my own
> timezone.
> 
> Whether or not the actual time storage is in UTC is irrelevant, since we
> know that all good OS's can convert a UTC time into a local time and
> vice versa.  The important thing is not to lose the piece of information
> about what timezone applies for calculation of future instances.
> 
> 
>> 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.
> 
> I would certainly not advocate for changing the storage of base dates
> from UTC.  Only that events might want to specify which timezone is to
> be used for calculation of repetitions.
> 
> 
>> 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.
> 
> In iCal on a Mac it is certainly possible to anchor an event to a
> particular timezone.  Likewise it works fine in Evolution on Linux
> (whence this interoperation debate springs from), or emClient on
> Windows.
> 
> 
>> 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?
> 
> For my example above, of the regular telephone conference, the time
> should always be anchored to the timezone in which the meeting time is
> defined.  At the moment I am some 17 hours ahead of America/New_York, so
> 11:00am Tuesday is a rather bleary-eyed 4:00am Wednesday for me but were
> I to fly to San Francisco over the weekend next week it would be a much
> more manageable 8:00am Tuesday in the America/Los_Angeles timezone.
> 
> 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.
> 
> 
>> 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?
> 
> 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.
> 
> 
>> 3.3) What happens if the user changes time zone permanently? Do you
>> find all the objects in the store and modify them?
> 
> I guess this is server dependent.  iCalendar allows for this by perhaps
> specifying a THISANDFUTURE override against the instance where it
> changes, but just because that's possible doesn't convince me it's a
> great idea to use that.
> 
> It seems to me that instances of the event which have occurred in the
> past must be assumed to have happened as scheduled, and in many cases it
> would be easier to end the previous event and create a new series based
> on the new time/timezone.
> 
> I don't think it would be a good idea to go back and change all of the
> old instances - that seems very unlikely to be what the user would
> expect to happen.
> 
> 
>> 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. 
> 
> Rather, perhaps, don't even *attempt* to describe *any* formula for
> calculation of daylight savings times.  There are standard libraries for
> performing these calculations on every platform and language that I am
> familiar with (most use the Olson rules, in reality) and I feel it would
> be better not to overspecify in this area.
> 
> Regards,
> 					Andrew McMillan.
> 
> -- 
> ------------------------------------------------------------------------
> http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
> Twitter: _karora                                  Phone: +64(272)DEBIAN
>  Ignorance is like cholera. It cannot be controlled by the individual
> alone: it requires the organised efforts of society. -- Sir Muir Gray
> 
> ------------------------------------------------------------------------
> 