openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Couple of test results for testing timezone in new Calendar UI
Date Wed, 31 Jul 2013 10:04:13 GMT
Use case 1:

Server is in CEST time zone, client browser/OS is in NZDT and openmeetings
user profile is in NZDT.


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
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.


Sebastian Wagner!/dead_lock

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message