Recurring events with timezone
tobias.koenig at kdab.com
Thu Oct 28 15:20:13 CEST 2010
On Thursday 28 October 2010 09:33:52 Hendrik Helwich wrote:
> Hi Tobias,
> > 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.
> The correct solution for UTC would be to convert the UTC time to the local
> time for every time the event happens. So in the example given above with
> the start time of 14:00 UTC of a recurring event, it is correct to show
> 16:00 in johannesburg all the year (constant offset of 2 hours), but in
> germany the time should be shown first at 16:00 but switch to 15:00 in the
> next month when the DST offset changes in germany.
?!? Sorry, but now I'm completly confused.
You said you want that also in Germany this event is _always_ shown at 16:00
indepentend of the current DST. So why should it be shown on 15:00 suddenly?!?
I mean it is shown at 15:00 currently, because the implementations are buggy,
but that's not correct. It should always show 16:00 for recurring events.
> > Can you give an example where this won't work?
> The problem is that it is a common use case that you want a recurring event
> to happen at a local time and you do not want that the start time changes
> over the year if you have DST in your local tz.
That completly contradicts your statement above :/
> And this cannot be managed with UTC time zone alone.
I _explained_ in my previous mail how this is possible with just storing the
UTC time in the kolab format and calculating the local time, depending on the
first occurence of the event and information about the local DST.
I don't know why, but I have the feeling you ignore every valid and logical
point against storing unnecessary timezone information inside the kolab
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...
Size: 3636 bytes
Desc: not available
More information about the format