I think this discussion is getting a bit off topic so I just wanted to reframe what I think is up for debate here. We decided a while back that timezone support was important for our target Chandler users. As Mimi mentioned, we have already worked through many of the questions/issues people are raising on the list. If there are questions about the decisions made etc for Chandler, we can refer people to more detailed specs/writeups to provide more context. Currently in the product, users can do the following... + Turn of and off timezone support. + Set a timezone for a specific event. + Set a timezone for their current calendar view. + Set a floating timezone for a specific event (ie: the event appears at 8:00pm regardless of timezone my view is in). + Set a floating timezone for the calendar view (ie: EventA at 3pm PST shows up at 3:00pm and EventB at 11:00am EST shows up at 11:00am). + By default (out of the box), timezone support is OFF which means everything is using floating timezones. This is the setup for people who don't care about timezones or want/need to have events show up in different timezones on different days of the same calendar view and therefore need to manage timezones in their head. + If you want the calendar canvas to know about timezones however, you can turn ON timezones. I understand there are some discussion around setting a default timezone which gets reset each time you run the app. We should probably have a separate conversation about this starting with the applicable use cases that support this scenario. In keeping with our ecosystem vision, this primary target user (person who will be dogfooding our Scooby calendar), will be a Chandler user that has shared their calendars onto Cosmo and wants to have web access to them or give others web access. For this reason, it's very important we maintain data integrity when viewing Chandler calendar data on Scooby. Users will expect a similar experience and to see things the same way. It would almost be better not to have any timezone support in Scooby rather than support it in a different way. Basically Scooby timezone support, as we implement it, needs to move in lock-step with Scooby for most issues. We do understand however that there are subtle differences in the way we need to handle certain things (storing defaults, persisting info across sessions) and these need to be discussed. Priscilla's original email was really about determining which release we try and do the timezone work in or if we can do that incrementally and is less about whether or not people care about timezones. At a product perspective, having timezones supported in 0.2 vs 0.3 doesn't really matter as long as it's there for whatever release we are calling our "dogfood scooby calendar". The 0.2 release is just a step along this path and not intended on satisfying any particular target user scenarios. It's my understanding that the development team feels we need to start on timezone support sooner rather than later and stage this. I think the real question to discuss here is "Can we implement some subset of the Chandler timezone functionality in Scooby so it's not confusing for users or do we really need to have the whole enchillada done in one release?" Sheila On Apr 20, 2006, at 11:29 AM, Jeremy Epstein wrote:
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
