SebastianWagner created OPENMEETINGS-728:
--------------------------------------------
Summary: Make Calendar UI timezone safe
Key: OPENMEETINGS-728
URL: https://issues.apache.org/jira/browse/OPENMEETINGS-728
Project: Openmeetings
Issue Type: Bug
Reporter: SebastianWagner
Assignee: SebastianWagner
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
