sheila at osafoundation.org
Mon May 2 17:40:29 PDT 2005
There was a thread circulating early regarding support for timezones
and recurrence in the context of sharing for 0.6. Brian Moseley
"one question: what level of support will we have for sharing timezones
and recurring items in 0.6? section 4.2 of the caldav draft talks about
how to store these things. also, if we're going to do any real sort of
timezone support, i will have to consider implementing a timezone
collection in cosmo as per sections 3.3 and 9.3."
I wanted to bring this discussion to the dev list....
Mimi and I are in the process of writing up the use cases that we want
to support for timezones in 0.6 and should be done in the next couple
of days. In brief, it will likely be similar to the way iCal works...
- specify a home timezone for viewing calendars.
- the user could potentially change this to some other locale.
- we wouldn't have timezones per calendar or collection, we would have
to pick one at a time for all calendars app. ie:PST
- we can specify a timezone for an event and it can be different than
the app timezone. ie: EST
- in this case the event would display in the context of the app
timezone (if it's 3:00pm EST, it would show up at 12:00pm)
- yes, we will have to share recurring events and events where the
timezone has been set.
This is by no means vetted and comprehensive at this point.
I had asked Jeffrey Harris about our strategy for timezones a few days
ago and he sent the following response.
Timezones are needed for recurrence, so every event will have an
of Kind timezone, that kind is yet to be defined. Getting this working
fully in the repository and with export to iCalendar is a significant
undertaking I've got on my list of things to do for 0.6.
I think there are two challenges in doing anything user-facing relating
timezones in 0.6:
A) My current plan is to work on timezones after most other recurrence
stuff is in place, this could be a problem to the extent that UI work
blocks on this (there might not be much dependence, perhaps we could
up dummy text and iron out presentation issues first)
B) If the user is going to get to choose from a list of possible
timezones, we have to get that list from somewhere. This is,
theoretically, a solved problem, dateutil now ships with a zoneinfo
database, but I haven't tested it yet
I'd lean towards making timezone presentation be an "if time allows"
feature for 0.6, but if we want to prioritize this higher, I could work
timezones earlier, or someone else could, it's an easy enough thing to
More information about the Dev