[Dev] Timezones/Recurrence/Sharing

Sheila Mooney 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 
asked....

"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.




More information about the Dev mailing list