"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 attribute
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 to
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 mock
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 on
timezones earlier, or someone else could, it's an easy enough thing to
hand off.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
