Recurring events with timezone

[Andrew McMillan]

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

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.kolab.org/pipermail/format/attachments/20101027/8c4b8231/attachment.sig>