Okay, after a bit of back and forth using the wicket-jquery-ui library I think it might be worth re-evaluating our timezone behaviour.
Basically it seems like the approach to show the UI in a timezone different from the users browser/os is a non common approach. And eventually we can directly migrate away from it. So the proposal would be: Show the calendar UI and any timezone relevant information in the browser's timezone. To resolve the issues in the invitations I would suggest the following changes: - When the user signs up the timezone is no more editable/not even shown maybe or read only and taken from the browser/client os - Everytime the user logs in the timezone field in the users profile is updated with the current timezone of the browser/client os. The idea might be that we add a new entry in the table OmTimeZone whenever we detect any user with a new timezone. - Login view the Flash application will no more be possible. The Openlaszlo application will only be used for the conference room itself By doing that it should basically all just work fine. But now comes the elefant :) We need a mapping between iCal4J timezones and java.util.Timezone. iCal4J is using net.fortuna.ical4j.model.TimeZone and we only have java.util.TimeZones. This is the historical reason why the code is a little bit messed up with various timezone calculations and fallbacks. So it will be a major refactoring that should be planned and broken down in several phases. We will change and touch all and any kind of functionality in OpenMeetings. It will require quite a bit of regression testing to check if nothing is broken. We generall said refactorings like this are not part of OpenMeetings 3.0. And once we start this there is no way back. It will delay any potential release by 1 - 2 months. What is the general opinion about this ? -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
