Recurring events with timezone

[Andrew McMillan]

On Sun, 2010-10-10 at 21:59 +0200, Gunnar Wrobel wrote:
> Hi Hendrik,
> 
> sorry for the delayed response.
> 
> Zitat von Hendrik Helwich <h.helwich at tarent.de>:
> 
> > Hi,
> >
> > i need to convert an iCalendar (from evolution) to the kolab format. It is
> > possible to create a recurring event in evolution which has a start and end
> > time in a timezone which is different to UTC. I think this is a reasonable
> > configuration.
> > In the kolab format it is only allowed to store time in UTC format [1].
> > Because of the summer and winter time i think it is not possible to convert
> > such an iCalendar to the kolab format (the UTC start and end time would
> > change over time).
> > How can i handle this problem?
> 
> I don't see a direct limitation there. The conversion to UTC is  
> certainly possible and valid while you are doing it to and from one  
> timezone. I see a problem once you are looking at the same event with  
> a client in a different timezone.
> 
> And to be honest I believe there are still some significant problems  
> when it comes to timezones on the Kolab server.
> 
> But maybe you can detail what the exact problem that you are having  
> with the conversion is.
> 
> I could imagine that you might also be able to solve your specific  
> problem by adding a custom attribute to the event XML.

Hi Hendrik,

The general problem with not associating timezone information repeating
events is that to calculate future instances of a repeating event you
will need to know when to apply / not apply daylight saving adjustments.

That weekly meting at 10:00am happened a different offset from UTC six
weeks ago than it will in six weeks time.

The offset from UTC is also not sufficient to define timezone, since an
offset of (e.g.) UTC-5 could be a northern country, an equatorial
country and a southern country, all having quite different daylight
saving rules.

In fact even the geographic location is not sufficient to define a
timezone, since in some cases there are multiple timezones overlapping a
geographic region due to cultural differences.  Recording the user's
intended timezone is the only sure way.

Obviously you can use a UTC time to know the correct time for an
instance of an event, although even here it is useful to know the
intended timezone of the event so you can (potentially) split the time
display to show the user's local time as well as the event's local time.

Regards,
					Andrew McMillan.
-- 
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
Facts do not cease to exist because they are ignored. -- Aldous Huxley,
                         "Proper Studies", 1927

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

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