I would default server time zone to the time zone of the server. It is up to admin to set it to the different value.
On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com < seba.wag...@gmail.com> wrote: > 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 > -- WBR Maxim aka solomax
