Basically the calendar is not timezone safe as it is now. There is no option 3 to just leave it as is from my point of view. So something has to happen.
Sebastian On 9 Aug 2013 20:19, "Maxim Solodovnik" <solomax...@gmail.com> wrote: > I don't really like the idea of having setting in the options which is > overwritten on every login (silently) > > My vote is for Alternative 2. > > @Sebastian > I guess Alternative 2 is for 3.1.0? I can try to perform refactoring > faster. Then you can handle "fine tuning" of this issue and I can handle > Import/Export (might be tricky) > > > On Fri, Aug 9, 2013 at 2:24 PM, seba.wag...@gmail.com < > seba.wag...@gmail.com > > wrote: > > > So probably we can put this up for a vote? > > > > The only alternative I see as a short term fix is to overwrite the users > > "OmTimeZone" with the current timezone of the browser. > > > > Alternative 1: > > Short term fix, default OmTimeZone to current timezone in browser, > > overwrite everytime the user logs in (Estimated 1-2 weeks of work) > > > > Alternative 2: > > Rewrite and refactor to get rid of entire OmTimeZone (as described in > > attached discussion or thread: > > http://markmail.org/message/rem2snf74srvftnt) > > (Estimated 1-2 months of work) > > > > The effort estimates are including time that is needed for fixing bugs > and > > do the testing. > > > > Vote for 1 if you like to see this implemented as part of OpenMeetings > > 3.0.0, vote for Alternative 2 if you want to see this implemented as part > > of OpenMeetings 3.0.0. > > > > Thanks, > > Sebastian > > > > > > 2013/8/8 seba.wag...@gmail.com <seba.wag...@gmail.com> > > > > > That is the major question. > > > > > > Basically status now is that the Calendar UI is not ready to be > released. > > > The UI is simply not working when your browser timezone is different > from > > > the timezone in your OpenMeetings profile. > > > > > > So either we can do the proposed fixes around getting rid of the > > > OmTimeZone completely or we try to do some kind of workaround in > > > OpenMeetings 3.0.0 and do the refactoring later. > > > > > > Sebastian > > > > > > > > > 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> > > > > > >> >>> Can we define any useful JUnit tests so that we don't need to do > so > > >> much manual testing ? > > >> I believe so, but what version will be affected with this change? > 3.0.0 > > or > > >> 3.1.0? > > >> > > >> > > >> On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com < > > >> seba.wag...@gmail.com > > >> > wrote: > > >> > > >> > "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." > > >> > ok > > >> > > > >> > "Additionally Appointment, I guess." > > >> > Nope, Appointment does not have timezone information. The start/end > > >> date of > > >> > the appointment is always in the server time zone. Actually _an_ > > >> date/time > > >> > that is stored is always the server time. > > >> > We only need timezone information when we need to display that time > > for > > >> any > > >> > _user_ to generate a localized representation of the date/time. > > >> > For instance an Appointment can be 8am GMT but for one user 1am > > >> GMT/Berlin > > >> > should be displayed as 6pm NZDT/Auckland and for yet another > > >> MeetingMember > > >> > it has to be displayed as 2am EDT/New York. > > >> > > > >> > So from my point of view the User, MeetingMember and Invitations > > Entity > > >> are > > >> > the right place. And that is already as it is now. So you can > replace > > >> > OmTimeZone in all those classes with the new attribute that stored > the > > >> > timezone. > > >> > > > >> > Can we define any useful JUnit tests so that we don't need to do so > > much > > >> > manual testing ? > > >> > > > >> > Sebastian > > >> > > > >> > > > >> > > > >> > 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> > > >> > > > >> > > 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 > > >> > > > > >> > > > >> > > > >> > > > >> > -- > > >> > 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 > > > > > > > > > > > -- > > 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 >
