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/08/01 13:28:29 UTC
Re: Couple of test results for testing timezone in new Calendar UI
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
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