I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such.
My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> > The correct URL is http://timezonepicker.com/ > > > On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <solomax...@gmail.com > >wrote: > > > I believe we can use something like this: https://timezonepicker.com > > (sources are here: https://github.com/quicksketch/timezonepicker) > > > > The only issues I can see right now: > > 1) it has no License set in the moment ( > > https://github.com/quicksketch/timezonepicker/issues/2) > > 2) It last updated 9 months ago > > > > So maybe additional googling is required :) > > > > > > On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com < > > seba.wag...@gmail.com> wrote: > > > >> One thing that is not on our list now is the default timezone of the > >> server. > >> Currently when you install OpenMeetings you choose a timezone. > >> > >> The questions are: > >> 1) Where do we populate the timezones from in that list, displaying 650 > >> timezones of java.util.Timezone is not practical > >> 2) If we default that timezone to some value, what shall it be? The > >> timezone of the server or the timezone of the client browser? > >> => In theory this default timezone is used whenever we can't find a > >> suitable timezone. So potentially we can default it to the browsers > >> timezone that is currently installing OpenMeetings. > >> This default timzeone will be used whenever there is no timezone > >> available for a user or if the timezone of the user is corrupted. > >> > >> Sebastian > >> > >> > >> > >> > >> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> > >> > >> > Additionally Appointment, I guess. > >> > Non-existent XML attribute will be ignored by simpleframework. > >> > > >> > I believe we can let timezones.xml live in our sources and convert > >> backups > >> > based on it > >> > > >> > > >> > On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com < > >> > seba.wag...@gmail.com > >> > > wrote: > >> > > >> > > That might be another approach. > >> > > So you are saying we get rid of the Entity OmTimeZone in total? > >> > > > >> > > Even if we have the timezone in the each of those object,I think > there > >> > > should be a fallback mechanism. Cause with every Java update (or I > >> think > >> > > you can even do it manually) you can get updates to the > number/offset > >> of > >> > > the timezones (appearently every year such and such countries for > >> > instance > >> > > "decide" to switch to have not a Daylight saving time, et cetera, or > >> > there > >> > > is even a brand new timezone). > >> > > So it could happen one day that we have timezone string in our > >> > application > >> > > that is neither known to java.util.Timezone nor to > >> > > net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one > and > >> > does > >> > > not exist in the other. > >> > > > >> > > I think we should go the extra mile and try to outline the technical > >> part > >> > > upfront doing anything concretly. It could save us a lot of time. > >> Also it > >> > > might be good to discuss this publicly as more then one person can > >> then > >> > > work on it in parallel. > >> > > > >> > > As far as I can judge you can't save the type java.util.Timezone in > a > >> > > database. > >> > > So it has to be either a string or you store an Integer > >> > > (utcTimeZoneOffset). But I really don't like the latter as it does > not > >> > > handle Daylight savings times. > >> > > > >> > > So the Entities that hold an attribute "omTimeZone" that would need > >> to be > >> > > changed: > >> > > User > >> > > Invitations > >> > > MeetingMembers > >> > > > >> > > and they all get a new attribute "String tz" > >> > > > >> > > How would we imagine could the export and import work if you import > an > >> > old > >> > > backup where the OmTimeZone is set in the user? I guess we need a > >> > converter > >> > > that can handle OmTimeZone to the new format. > >> > > However would that even work currently with > >> > > org.simpleframework.xml.Element, when you have an attribute that > does > >> > just > >> > > no more exist ? > >> > > > >> > > Any other considerations that are not yet covered? > >> > > > >> > > Sebastian > >> > > > >> > > > >> > > > >> > > > >> > > 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> > >> > > > >> > > > 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 > >> > > > > >> > > > >> > > > >> > > > >> > > -- > >> > > 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 > >> > > >> > >> > >> > >> -- > >> 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 > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
