Recurring events with timezone

Bernhard Reiter bernhard at intevation.de
Thu Nov 4 17:39:25 CET 2010


On Thursday 28 October 2010 16:07:14 Tobias König wrote:
> > User A lives in Germany and makes appointments with users B, C, D who
> > live in the United States, South Africa, and Brazil. They meet via video
> > conference every Monday 10:00 local German time, because that is when
> > user A booked the teleconferencing room to allow others from the local
> > team to join the meeting.
>
> Ahh, now things starts to clear up. I assumed the problem is displaying the
> UTC time depending on recurring events, but here we have the 'change UTC to
> follow a specific local time' problem.

Yes, Georg's describtion has been the best I've read so far.

Or rephrased:
We all know that one UTC datetime determines date and time pretty
well and all clients know to display this in their timezone and how
to change it.

The problem comes in, 
when we have to calculate a second appointment in the series. 
If this appointment has been crossed any daylight saving time change
from the first occurance, it get unclear what should be done
in the clients if they are in timezones that differ in their shift
of the time. To create a problem, this shift needs to be on a different 
datetime or being a shift for a different number of hours.

I believe Joon, Tobias and some others did not see the point, because it is 
working already across a number of timezones if they shift similiar.
It works because each of the clients will calculate the second datetime
correctly because it considers the same shifting, despite being in different 
timezones.

Complication 1: The user wants to chose, even if she is in the German 
timezone, if the second event should be "sticky" to the timezone or not.
I first thought this was a different issue, but you can also regards this
a special case of the first problem
if the user wants to chose the timezone for the appointment.
If the user just selects UTC+1 or UTC+2 instead of Germany/Berlin
the second appointment will not be "sticky".

Complication 2: Some people would want to know even which timezone the first
appointment is taking place. This might be interesting to know for 
communications, but it seems to be unrelated to the other issues.

> In this case there are two solutions: Either the client, which creates the
> recurring event, splits the event up in two recurring events, one for each
> DST mode. Then during summertime a recurring event with 08:00 UTC is used
> and during winter one with 07:00 UTC.

If you want to change the recurring event then, you would need to know
when daylight shifts to switch the appointment from within one rule to the 
other. If you do not know the timezone, you do not know the precise hour
when the shift happens. So other clients could not do the move of an hour 
correctly and still have both appointment distances match in one timezone.

> And the other solution is indeed the storage of timezone information inside
> the format. So sorry for the confusion and thanks for the example!

Complication 3: Daylight saving is changing over time, which makes it hard to 
predict how a "sticky" appointment would behave it three years. The daylight 
saving might have changed. I cannot say how daylight saving databases deal 
with the problem. Technically this would lead me to save the first appointment 
base time in UTC always to have a stable basis. Now there are two 
possibilities: Either describe the timezone with the appointment or refer
to a well defined database. Both has its advantages and disadvantages
and would need to be discussed.

a) describing the timezone inline:
  Negativ: wastes some space in each appointment
  Negativ: would not change on (rare) timezone changes
  Positiv: stable unique interpretation over many years
  Positiv: saves time on the client to hold a large database for all zones

b) refering to a well defined database:
  Positive: Would update with updates of the database, but
  Negative: the client might have different revisions of the database
  Spave more wasted once in the client.

Overall option a) sounds slightly better to me.

Best,
Bernhard
 
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101104/70b5db6c/attachment.sig>


More information about the format mailing list