Recurring events with timezone

[Joon Radley]

Hi Andrew,

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

UTC is the constant. You calculate your local time by adjusting UTC to your local time zone. If at any point your software assumes that UTC is not the constant you need to revisit it.

Time zone and daylight savings time is a locale issue.

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 20 Oct 2010, at 9:43 AM, Andrew McMillan wrote:

> 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
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format