You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2013/07/31 12:04:13 UTC
Couple of test results for testing timezone in new Calendar UI
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
seba.wagner@gmail.com
Re: Couple of test results for testing timezone in new Calendar UI
Posted by Maxim Solodovnik <so...@gmail.com>.
fixed
On Fri, Aug 2, 2013 at 11:11 AM, Maxim Solodovnik <so...@gmail.com>wrote:
> https://issues.apache.org/jira/browse/OPENMEETINGS-726 almost fixed :)
>
>
> On Thu, Aug 1, 2013 at 7:20 PM, Maxim Solodovnik <so...@gmail.com>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, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> > 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
>>> > seba.wagner@gmail.com
>>> >
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: Couple of test results for testing timezone in new Calendar UI
Posted by Maxim Solodovnik <so...@gmail.com>.
https://issues.apache.org/jira/browse/OPENMEETINGS-726 almost fixed :)
On Thu, Aug 1, 2013 at 7:20 PM, Maxim Solodovnik <so...@gmail.com>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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>
>> > 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
>> > seba.wagner@gmail.com
>> >
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: Couple of test results for testing timezone in new Calendar UI
Posted by Maxim Solodovnik <so...@gmail.com>.
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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 seba.wagner@gmail.com <se...@gmail.com>
>
> > 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
> > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: Couple of test results for testing timezone in new Calendar UI
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 seba.wagner@gmail.com <se...@gmail.com>
> 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
> seba.wagner@gmail.com
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com