fixed
On Fri, Aug 2, 2013 at 11:11 AM, Maxim Solodovnik <[email protected]>wrote: > https://issues.apache.org/jira/browse/OPENMEETINGS-726 almost fixed :) > > > On Thu, Aug 1, 2013 at 7:20 PM, Maxim Solodovnik <[email protected]>wrote: > >> I'll try to take a look at it, or will ask Vasiliy >> Thanks for the investigation! >> >> >> On Thu, Aug 1, 2013 at 6:28 PM, [email protected] < >> [email protected]> wrote: >> >>> I have transfered point no 4) to: >>> >>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/List+of+Missing+Features+OpenMeetings+3.x >>> >>> Basically the issue is that in past versions a calendar event that you >>> created showed in all Calendaer UIs of the users that you have invited >>> if >>> those are OpenMeetings users. >>> >>> Thanks, >>> Sebastian >>> >>> >>> 2013/7/31 [email protected] <[email protected]> >>> >>> > Use case 1: >>> > >>> > Server is in CEST time zone, client browser/OS is in NZDT and >>> openmeetings >>> > user profile is in NZDT. >>> > >>> > Issues: >>> > >>> > 1) Wrong default time in new event >>> > >>> > When you login and click on any day in the month view it will open the >>> > popup for entering the new event, but the default time will be the >>> current >>> > date time of the _server_ instead of defaulting it to the client >>> > >>> > 2) Wrong time in invitation email and iCal event (This could be split >>> up >>> > into two issues, email and iCal) >>> > >>> > When the user creates a meeting at 21:19 NZDT to 22:19 NZDT the >>> invitation >>> > show the time string: >>> > Start: 01.08.2013 07:19:00 NZST (+1200) >>> > End: 01.08.2013 08:19:00 NZST (+1200) >>> > >>> > 3) Invitation link with hash does not work for external users >>> > >>> > If you create the event with start and end date from at 21:25 NZDT to >>> > 22:25 NZDT >>> > the hash does not work, it will show you the event takes place at: >>> > You invitation code is not valid, the code is only valid during this >>> > specific date and time: >>> > Thu Aug 1 07:25:00 GMT+1200 2013 >>> > - >>> > Thu Aug 1 09:25:00 GMT+1200 2013 >>> > >>> > Which is of course wrong. >>> > >>> > 4) Internal users do not show calendar events of events that you have >>> been >>> > added to >>> > >>> > When you create an event and add any _internal_ user, then you login >>> with >>> > that invited internal user, >>> > this new event does not show at all in the calendar of the invited >>> user. >>> > => I suspect also there there the timezone won't be correct, simply by >>> > looking at the timestamps in the database, however at first instance we >>> > have to fix that those users have the event shown in their calendar at >>> all >>> > (as it was previously) >>> > >>> > 5) Invitation email of invited internal user shows wrong timezone >>> > >>> > Previously if you invited an internal user, I think the email showed >>> the >>> > timezone of the invited user not of the "event origanizer". Cause the >>> > invited user is of course not interest in what other timezone this will >>> > happen, he is interested when this event will happen >>> > in _his_ timezone. Same for the iCal event this user receives. >>> > And every internal user has an timezone in his user profile. >>> > >>> > >>> > 6) Changing the timezone in the user profile has zero effect on how it >>> > will be displayed in the UI >>> > >>> > If you go with the user from use case 1 in the user profile and change >>> it >>> > from NZDT to NewYork (EDT - Eastern Daylight Time), and then go back >>> to the >>> > Calendar UI, the UI will show you _exactly_ the same as before. >>> Actually >>> > all date and times should be now shown in EDT but it still shows the >>> same >>> > as before. Also if you relogin, it just does not handle the timezone >>> at all >>> > >>> > Use Case 2: >>> > >>> > Server is in CEST time zone, client browser/OS is in NZDT and >>> openmeetings >>> > user profile is in EDT (NewYork Eastern Daylight Time). >>> > >>> > 7) Repeating the issue of 2) but this time the time offset is >>> different: >>> > >>> > I created in the Calendar UI an event starting at 21:39 pm ending at >>> 23:39 >>> > pm (openmeetings user profile is set to EDT) >>> > The Email contains the information: >>> > Start: 31.07.2013 15:39:00 EDT (-0400) >>> > End: 31.07.2013 17:39:00 EDT (-0400) >>> > Which is a simply wrong but besides that a different offset and >>> > calculation from issue 2) where browser/OS timezone and the >>> openmeetings >>> > user timezone in his profile have been the same >>> > >>> > 8) Inviation has shows wrong date and time (same as in 3)) but the >>> > timezone offset is different again, >>> > >>> > When you click on the link the invitation shows: >>> > You invitation code is not valid, the code is only valid during this >>> > specific date and time: >>> > Thu Aug 1 07:39:00 GMT+1200 2013 >>> > - >>> > Thu Aug 1 09:39:00 GMT+1200 2013 >>> > >>> > >>> > => So from my point of view the issues 7) +8) of use case 2 shows that >>> > there is a strong indication of what I suspected: >>> > When you set the timezone in the openmeetings profile different from >>> the >>> > operating system on the client browser >>> > it makes a difference, the offset and calculation is different from use >>> > case 1. >>> > >>> > Besides that there are a number of other issues with the timezone >>> handling. >>> > >>> > I don't know how we want to approach the problem, however mucking >>> around >>> > with +/- timezone offsets is really a very hard job. >>> > It will be easier if you transfer the time to the server in yyyy-mm-dd >>> > HH:MM >>> > and on the server make something like: >>> > >>> > //Assuming the date/string "yyyy-mm-dd HH:MM" would be 2013-11-23 21:25 >>> > >>> > Calendar cal = Calendar.getInstance(); >>> > cal.setTimezone(timezone); //get timezone from user profile >>> > cal.set(Calendar.Day, 23); >>> > ... set month, year, minute, hour >>> > >>> > >>> > The way it is currently with java.util.Date is just very confusing >>> cause >>> > you never >>> > know then what timezone the date you are looking at really is. >>> > >>> > I can asure that I have been messing around with those issues for >>> quite a >>> > while, there will be nothing magically work. We have to know exactly >>> what >>> > we handle in the browser, in what format and timezones the date object >>> is >>> > transfered to the server and in what timezone we save it in the db >>> server. >>> > And we need to know through the entire lifecycle/flow of any date >>> > representation in "yyyy-mm-dd HH:MM" (no matter if its a string or >>> > java.util.Date or whatever in the end) in what timezone any date/time >>> is. >>> > >>> > Thanks, >>> > Sebastian >>> > >>> > -- >>> > Sebastian Wagner >>> > https://twitter.com/#!/dead_lock >>> > http://www.webbase-design.de >>> > http://www.wagner-sebastian.com >>> > [email protected] >>> > >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
