I like the idea of having less custom issues I believe TZ field in all our objects can easily be just a string like: "Europe/Berlin"
On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik <solomax...@gmail.com>wrote: > I have: It is impossible to get User timezone (you only can get tz shift > and/or dst shift and if dst is in effect) > > According to iCal4J time zone mapping I guess the name should be the same > > > On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com < > seba.wag...@gmail.com> wrote: > >> 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 >> > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
