Recurring events with timezone

[Andrew McMillan]

On Mon, 2010-10-11 at 12:01 +0200, Georg C. F. Greve wrote:
> 
> Storing in a variable base seems fundamentally broken to me, in particular 
> when you take multiple time zones into account. So when a meeting takes place 
> in two timezones which switch to daylight saving time at different times, when 
> is that meeting supposed to be? Which of the local time stores wins?

Hi Georg,

I regularly participate in teleconference calls among people in several
countries.  The bulk of the participants are usually in one particular
country, and they arrange the time of the event, so they declare it to
be at an invariant local time.  Local to them.

People in the rest of the world are at a disadvantage in such a
situation, since they have to convert that time to their own local time
in order to be able to attend the teleconference and they do not have
the luck to attend at an invariant local time.  In my case this often
means getting up very early and going back to bed afterwards, and (when
I use bad software, or have out-of-date timezone definitions) missing a
meeting or two around DST boundaries.

Software which does not support storing timezones is a lot less useful
to normal people in such situations.  People in New Zealand would almost
never be interested in scheduling stuff in UTC, because the addition &
subtraction of 12/13 hours very easily introduces mistakes.  Possibly
the use of UTC as a standard is more appealing to people living within a
few hours of it.


> If it is stored in UTC, at least there is a firm point of reference against 
> which it can be calculated. But there should be some way to identify what 
> happens in these DST conflicts. IIRC my discussions with Bernhard that has been 
> on the list of issues to resolve for the format for some time now.

What happens is necessarily defined by the user controlling the event
time.  Some users will want a repeating event to be localised to a
timezone which has daylight savings time such as Europe/London,
Europe/Lisbon, Antarctica/McMurdo or Asia/Kamchatka, and others might
want it localised to a timezone which does not, such as UTC, or
Pacific/Fiji.


> So the question is: What would be the right way of treating it?

The right way is to leave the decision to the person creating the event,
allowing them to include a timezone identifying the local time of the
event.  They might then say that the local time zone is "UTC" if that is
what they want.  The use of UTC in this way seems to be a more common
approach for fairly geeky groups, but my own experience suggests that
teleconferences involving higher level managers generally seem to be
scheduled in someone's local timezone.


> Storage in UTC, as before, with an additional field that defines the behaviour 
> for DST? I could envision such a field to define that an event (a) stays with 
> UTC, or that (b) it stays synchronous with local time zone X.

UTC is not really any more than "another timezone".  It just happens to
be the one that is used as a reference for all of the others, but there
are plenty of other timezones which have no-op DST specifications.


> That might be a clean solution. But how would this work with synchronization, 
> e.g. the ActiveSync protocol? Does anyone know off the top of their head how 
> this is handled there?

ActiveSync supports including a timezone with the event.


The generally accepted standard is to use iCalendar, which every
calendaring program that I know of supports for import/export, and which
is almost always used for interoperability (e.g. iTIP/iMIP messaging)
and regularly used as the basis for designing the program's internal
representation.  In fact you can see in the ActiveSync calendaring
specification that the timezone structure almost exactly maps to a
simple iCalendar VTIMEZONE structure.

iCalendar specifies the ability to define arbitrary timezones (VTIMEZONE
component) which are identified by a TZID and which can then be
referenced with the TZID property from most user-facing dates in the
other components of a VCALENDAR.

Most implementations use the Olson timezone definitions underneath, and
it is very common to see the Olson name as the TZID, although somewhat
less common for US timezones.

The proposed xcalendar format is based on mapping the iCalendar data
structure into XML while retaining bidirectional convertability.

Regards,
					Andrew McMillan
-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
           It is the wise bird who builds his nest in a tree.
------------------------------------------------------------------------

-------------- 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/20101011/7127b364/attachment.sig>