Recurring events with timezone

Tobias König tobias.koenig at kdab.com
Wed Oct 27 18:41:34 CEST 2010


On Wednesday 27 October 2010 16:50:25 Hendrik Helwich wrote:
> Hi Tobias,
Hej Hendrik,

> Example: if i have a local german tz and i create a recurring event from
> today which starts at 16:00 every day, in the kolab format there is a
> startdate of 14:00 UTC stored (current DST offset of 2 hours) and the rule
> to repeat this event every day. Kontact/Toltec show me a start date of
> this event of 16:00 even if UTC offset changes due to the local DST rules
> in the next month.
Then the implementation of converting UTC->localtime for recurring events is 
broken in Kontact/Toltec!

For recurring events the clients should not add the _current_ DST offset
to the UTC for getting the local time, but the DST offset at the point of the 
first occurence of the event.

If you create an recurring event at 16:00 (DST+2) then you want it to be there
in (DST+1) at 16:00 as well. So you can't add the current DST offset for 
recurring events.

Can you give an example where this won't work?

> So in this example the storage xml is the same and the shown local times in
> the clients are the same.
That's correct, because UTC is always the same, it is the constant thing in 
time calculation.

> But this is obviously wrong because both tzs have different DST rules and
> the same kolab event is shown the same in the clients all the year.
Like I said, that's a bug in the implementations.

> This is because of trying to fix the format by applying local DST rules to
> get the UTC time.
You have to fix the clients, not the format!

> No, the clients need the information of the DST rules of the events tz.
No, they need the information of the DST rules of the local tz at the point in 
time when the event has been created.

> Otherwise it is not possible to calculate the correct UTC times of the
> dates.
UTC is contant! You don't have to calculate it. Take UTC as the base and 
calculate all locale times from it.

> > No, there is no event tz, events are always stored in UTC.
> 
> Yes this is right. But the problem is that it is done wrong in the moment,
> so one solution would be to calculate UTC -> local correct
Exactly, that's the way to do it!

> or another solution would be to add event tz to the kolab format
> and calculate event tz -> UTC -> client tz
No, definitely not. If you have N timezones, then

  'UTC -> local' needs N possible conversions

but

  'local -> UTC -> local' needs NxN possible conversion

what do you think is easier to implement and maintain?

Ciao,
Tobias
-- 
Tobias Koenig | tobias.koenig at kdab.com
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20101027/6abd0eb8/attachment.p7s>


More information about the format mailing list