Recurring events with timezone

[Georg C. F. Greve]

Hi Tobias,

I'm not sure that I understood your explanation then.

Allow me to try and explain the case I believe has been discussed:

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.

If that meeting was made in the summer, the event gets stored as 08:00 UTC.

The guy in South Africa gets off easy, no DST. ;)

Time zones do however change in Germany, United States and Brazil for daylight 
saving times, these changes typically happen on different dates, and (for 
Brazil) in different directions. The difference between Germany and Brazil can 
be anything from three to five hours, depending on the week.

With a strict UTC based calendaring, the event would move to 09:00 on Mondays 
in Germany - but at least it would allow to keep all time zones consistent, as 
every client knows to obey UTC strictly.

But the user would like the event to be 10:00 on Mondays according to German 
local time, and all other clients should calculate their time accordingly.

Now that is of course possible with storage of the time in UTC, but ONLY if 
the client knows whether this event was set with DST in effect or not, and ONLY 
if it knows which time zone this event should be "sticky" to.

And finally, the same event should be possible to set by user A, B, C or D, so 
cannot be taken from the user's time zone. It needs to be user determined.

That is why Hendrik proposed to introduce time zones into the time storage, as 
the time zone used would implicitly be used to set which time zone is sticky.

Others have correcly pointed out that the "sticky time zone" bit could be 
introduced into other fields, as well, in order to disrupt other clients as 
little as possible.

Can you explain to me how this use case is currently addressed?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101028/9ba848d2/attachment.sig>