Recurring events with timezone

Andrew McMillan andrew at morphoss.com
Wed Oct 20 09:43:01 CEST 2010


On Tue, 2010-10-19 at 09:07 +0200, Joon Radley wrote:
> Hi,
> 
> > For example, could you please tell me exactly when, in UTC, each of the
> > twelve instances next year will occur for a monthly meeting which was
> > initially scheduled for the 9:00am on the 1st of the January this year
> > in a timezone which (at that time) was aligned with UTC.
> 
> Does your locale functionality of your OS not provide this? If you
> have it in one time zone in the object and you have to calculate the
> dates for another user in a different time zone you still have to
> convert the original time: original local time -> UTC -> new local
> time. So in the new locale the original time zone is of no value
> except for calculating UTC.

I forgot to mention that the event in question is a teleconference among
three people in different countries.  We've all agreed which country's
timezone applies to the event, however it is not mine and nor is it UTC,
but some timezone with a non-constant offset from UTC.

Sadly, the event data I receive from the Kolab version of the event
doesn't tell me which timezone to do my calculations in, and yet I must
know that in order to correctly calculate the actual instance times
(whether I calculate the instances in UTC or not is irrelevant).


> > Certainly it would be possible to store some limited set of recurring
> > instances on creation of the event, though that is obviously a lossy
> > operation. Especially for events which are set to recur forever.
> 
> This assumes that everyone is in the same time zone. Each user only
> wants to see his appointments in his time zone. Else you will have to
> extend the format to include the time zone of each attendee as well as
> the time zones for their travel plans.

I think you over-assume what people actually want, rather than build
flexibility to let them choose, but in any case that's a matter for the
presentation layer and happens after we know when the instances of an
event will occur.


> Converting from UTC to your locale solves this problem without trying
> to figure out everyones time zone. Locale is a function of the OS and
> not the format.

Locale can very definitely be a function of the event.  I have a number
of teleconferences which are specified as occurring 'every fortnight, at
such and such time in the US/Eastern timezone'.  While the OS knows
about both my timezone and the US/Eastern timezone, if I only know the
UTC time for the original starting event, and then apply DST rules for
my local timezone, my local client will display the event at the wrong
time quite regularly.


> Well again this is a client issue. Assuming all other clients except
> yours is broken alway points to a incorrect perspective. The KolabXML
> format is locale independent. The clients can show the data in the
> locale they want.

Equally, please do not assume that everyone else who does it differently
is wrong.  Especially where there are long-standing and widely adopted
standards within the 'does it differently' set.

A repeated lack of understanding of this issue was one topic of
discussion at the recent meeting of the Calendaring and Scheduling
Consortium I attended in Massachusetts earlier this month.

Regards,
					Andrew McMillan.
-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
             If at first you don't succeed, try, try again.
                            -- W. E. Hickson

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

-------------- 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/20101020/d5fdd6b9/attachment.sig>


More information about the format mailing list