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/27 09:51:48 UTC
Is the Calendar UI timezone safe ?
I have a question around the jQuery Plugin for the Calendar UI that we are
using now.
I don't see how this will exactly handle time zones.
>From what I can see in the source code is that it is using heavily the
java.util.Date to set and get the date. java.util.Date does not handle
timezones at all. The right clas would be java.util.Calendar.
I don't know if the concept of the timezone handling was clear to everybody
so far:
Database fields don't care about timezones. That is why in the table/entity
"Appointment" the Date is simply a java.util.Date (not a timezone safe
java.util.Calendar). Cause if you would use "java.util.Calendar" the
database would simply cut away the timezone info! That is why it is Date
and not Calendar. Databases simply don't care about timezones. A database
field "datetime" is simply YYYY-MM-DD HH:MM:SS => and no timezones.
So the general message is: The date/time that is stored in the database is
always _in the local time of the server_ (or more correctly: In the time of
the database server).
In general that does not really generate a problem, as long as you know
this behavour.
However the end users of course often live in a completely different
timezone as the server, and also every user can set up their own timezone
in their user profile. So the timezone of the browser not neccessarly
matches the user settings.
I see a number of (FIXME) in the source code when it comes to the date
timezone conversion.
Stuff like this:
cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
To be honest I don't like that at all. You should never add or remove
anything to convert a time from one timezone to another.
Time is always the same, it never can happen that you ever add or remove
anything to it. The only thing that changes is the timezone. Not the time.
That means if you want to transfer 5pm from CEST to NZD.
The right Java class to do that is: java.util.Timezone.
So something like:
Calendar cal = Calendar.getInstance();
cal.setTimeZone(timezone); // which is then a java.util.Timezone
However if the Calendar UI does _not_ support java.util.Calendar we have a
problem.
For instance the method "onSubmit" this "Date" (start) in which timezone
will it be? Server's ? Client's? Browser settings? User profile ? What is
it ?
Try to think through this use case for example: Anybody can configure that
his user profile is in Sydney, Australia Daylight time, but according to
his browser/Operating system he would be currently in Berlin, Europe
central time, and the server itself is in New York(I think America Eastern
Daylight Time).
So what time is the meeting scheduled if he adds a new event at 3pm? Is it
3pm Paris, 3pm New York or 3pm Sydney ?
There is really no way to add a little bit of time here and there and then
remove it somewhere else: You really need to know exactly what timezone you
are currently handling.
Thanks,
Sebastian
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Is the Calendar UI timezone safe ?
Posted by Maxim Solodovnik <so...@gmail.com>.
I would like to propose to make some tests, then continue this discussion.
I believe everything should work as expected out-of-the-box.
Unfortunately I have not much free time these days :(
On Wed, Jul 31, 2013 at 10:19 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> This might be one way, however we should try to avoid "adding" or
> "removing" time.
> The time itself never changes. Its just the timezone. The probably best
> class for that is java.util.Calendar and java.util.Timezone.
>
> However we can discuss this issue for ages.
> You really have to go into the details and test and verify all those use
> cases.
> So lets do that and discuss then the next steps.
>
> Sebastian
>
>
> 2013/7/31 Alexei Fedotov <al...@gmail.com>
>
> > AFAIU
> > Maybe this is not the best way, yet one can use the following
> > javascript method to calculate a time zone:
> >
> > > getTimezoneOffset()
> > --
> > With best regards / с наилучшими пожеланиями,
> > Alexei Fedotov / Алексей Федотов,
> > http://dataved.ru/
> > +7 916 562 8095
> >
> > [1] Start using Apache Openmeetings today,
> http://openmeetings.apache.org/
> > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> > [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
> >
> >
> > On Wed, Jul 31, 2013 at 9:34 AM, seba.wagner@gmail.com
> > <se...@gmail.com> wrote:
> > > "Unfortunately there is no such thing as "browser timezone" :("
> > > There is the operating system timezone.
> > > And when you pass the date object via JavaScript to the server, the
> > > question is what timezone this date represents.
> > > For instance if the operating system has the timezone NZDT those
> > Date/Times
> > > will be transfered with a Date Object that has NZDT time.
> > > If the user has configured his Calendar UI to show in CEST time, the
> > wrong
> > > time will be transfer when the user submits for instance 5pm. The
> browser
> > > will submit it as 5pm NZDT but the user meant 5pm CEST.
> > >
> > > I have been mucking around with that stuff for weeks. Translating
> server
> > > and client side times is not that hard.
> > > It all seems to work fine.
> > > But you will realize very soon that users will want to configure
> > different
> > > timezones for their OpenMeetings user profile then from their device.
> > > And this is where the huzzle starts :0
> > >
> > > Sebastian
> > >
> > >
> > > 2013/7/31 Maxim Solodovnik <so...@gmail.com>
> > >
> > >> Unfortunately there is no such thing as "browser timezone" :(
> > >>
> > >> According to my observations all events in calendar are displayed as
> > >> expected.
> > >> According to Google FullCalendar being used as our JS library is TZ
> > safe if
> > >> TZ is stored somewhere (If I'm not mistaken we are storing TZ for
> every
> > >> event)
> > >>
> > >> I would ask Irina to test it :) or maybe to write test plan :)
> > >>
> > >> Currently I feel this version works as good as 2.1.1, need to finish
> and
> > >> release it :)
> > >>
> > >>
> > >> On Tue, Jul 30, 2013 at 8:19 PM, Alexei Fedotov <
> > alexei.fedotov@gmail.com
> > >> >wrote:
> > >>
> > >> > If a browser timezone is not set, one can use a server time zone
> > >> > assuming people work locally. For some countries like Germany which
> > >> > are in one timezone this works well for national wide conferences.
> > >> > --
> > >> > With best regards / с наилучшими пожеланиями,
> > >> > Alexei Fedotov / Алексей Федотов,
> > >> > http://dataved.ru/
> > >> > +7 916 562 8095
> > >> >
> > >> > [1] Start using Apache Openmeetings today,
> > >> http://openmeetings.apache.org/
> > >> > [2] Join Alexei Fedotov @linkedin,
> http://ru.linkedin.com/in/dataved/
> > >> > [3] Join Alexei Fedotov @facebook,
> > http://www.facebook.com/openmeetings
> > >> >
> > >> >
> > >> > On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
> > >> > <se...@gmail.com> wrote:
> > >> > > What kind of "default" timezone will be used, is another question
> > from
> > >> my
> > >> > > point of view.
> > >> > >
> > >> > > Still the calendar has to be able to show the UI in whatever
> > timezone
> > >> the
> > >> > > user selects in his profile settings. Independent what is
> > configured in
> > >> > the
> > >> > > Browser and Operating system and on the server side. And currently
> > I am
> > >> > not
> > >> > > sure if we can do that.
> > >> > > There are a number of use cases we have to play through to check
> > that
> > >> > out.
> > >> > > Also for instance:
> > >> > > 1) The invitation hash generated are only valid during the time of
> > the
> > >> > > meeting
> > >> > > 2) And for instance when you use that link you will see a popup in
> > the
> > >> > > conference room that shows the start and end date of the meeting.
> > >> > > Both is relevant to have the correct timezones set. Or what
> happens
> > if
> > >> > you
> > >> > > change the meeting time in the Calendar UI, will the update email
> > >> > correctly
> > >> > > include new hashs with updated times in the correct timezone (or
> > maybe
> > >> it
> > >> > > edit the existing ones, I am not sure at this moment what we had
> > >> > > implemented in OpenMeetings 2.x.)?
> > >> > >
> > >> > > Some of those functionality will be simply re-used from
> OpenMeetings
> > >> 2.x.
> > >> > > But the UI somehow has to reflect that or we will not only re-code
> > the
> > >> > > client side but also the server side.
> > >> > >
> > >> > >
> > >> > > Sebastian
> > >> > >
> > >> > >
> > >> > > 2013/7/30 Alexei Fedotov <al...@gmail.com>
> > >> > >
> > >> > >> Hello Sebastian,
> > >> > >>
> > >> > >> AFAIU the timezone code should take browser locale into account,
> > thus
> > >> > >> it should be client side javascript at the first place.
> > >> > >>
> > >> > >> This means unless you reconfigure your notebook from Germany to
> > Sidney
> > >> > >> time you never get meetings in the proper time. My phone already
> > makes
> > >> > >> an automatic switch based on carrier's data - this will be
> > propagated
> > >> > >> to computers sooner or later.
> > >> > >>
> > >> > >> Vasily, what do you think?
> > >> > >> --
> > >> > >> With best regards / с наилучшими пожеланиями,
> > >> > >> Alexei Fedotov / Алексей Федотов,
> > >> > >> http://dataved.ru/
> > >> > >> +7 916 562 8095
> > >> > >>
> > >> > >> [1] Start using Apache Openmeetings today,
> > >> > http://openmeetings.apache.org/
> > >> > >> [2] Join Alexei Fedotov @linkedin,
> > http://ru.linkedin.com/in/dataved/
> > >> > >> [3] Join Alexei Fedotov @facebook,
> > >> http://www.facebook.com/openmeetings
> > >> > >>
> > >> > >>
> > >> > >> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
> > >> > >> <se...@gmail.com> wrote:
> > >> > >> > I will try to make some tests here.
> > >> > >> >
> > >> > >> > I just wonder: Is everybody involved clear with that design and
> > what
> > >> > >> needs
> > >> > >> > to be done?
> > >> > >> >
> > >> > >> > Beeing timezone safe is a major criteria for the Calendar UI to
> > be
> > >> > >> > released. It was already an annoying thing that raised issues
> > over
> > >> > years
> > >> > >> in
> > >> > >> > OpenMeetings until it got fixed in the past :)
> > >> > >> >
> > >> > >> > Sebastian
> > >> > >> >
> > >> > >> >
> > >> > >> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> > >> > >> >
> > >> > >> >> I have a question around the jQuery Plugin for the Calendar UI
> > that
> > >> > we
> > >> > >> are
> > >> > >> >> using now.
> > >> > >> >>
> > >> > >> >> I don't see how this will exactly handle time zones.
> > >> > >> >>
> > >> > >> >> From what I can see in the source code is that it is using
> > heavily
> > >> > the
> > >> > >> >> java.util.Date to set and get the date. java.util.Date does
> not
> > >> > handle
> > >> > >> >> timezones at all. The right clas would be java.util.Calendar.
> > >> > >> >>
> > >> > >> >> I don't know if the concept of the timezone handling was clear
> > to
> > >> > >> >> everybody so far:
> > >> > >> >> Database fields don't care about timezones. That is why in the
> > >> > >> >> table/entity "Appointment" the Date is simply a java.util.Date
> > >> (not a
> > >> > >> >> timezone safe java.util.Calendar). Cause if you would use
> > >> > >> >> "java.util.Calendar" the database would simply cut away the
> > >> timezone
> > >> > >> info!
> > >> > >> >> That is why it is Date and not Calendar. Databases simply
> don't
> > >> care
> > >> > >> about
> > >> > >> >> timezones. A database field "datetime" is simply YYYY-MM-DD
> > >> HH:MM:SS
> > >> > =>
> > >> > >> and
> > >> > >> >> no timezones.
> > >> > >> >>
> > >> > >> >> So the general message is: The date/time that is stored in the
> > >> > database
> > >> > >> is
> > >> > >> >> always _in the local time of the server_ (or more correctly:
> In
> > the
> > >> > >> time of
> > >> > >> >> the database server).
> > >> > >> >> In general that does not really generate a problem, as long as
> > you
> > >> > know
> > >> > >> >> this behavour.
> > >> > >> >>
> > >> > >> >>
> > >> > >> >> However the end users of course often live in a completely
> > >> different
> > >> > >> >> timezone as the server, and also every user can set up their
> own
> > >> > >> timezone
> > >> > >> >> in their user profile. So the timezone of the browser not
> > >> neccessarly
> > >> > >> >> matches the user settings.
> > >> > >> >>
> > >> > >> >> I see a number of (FIXME) in the source code when it comes to
> > the
> > >> > date
> > >> > >> >> timezone conversion.
> > >> > >> >> Stuff like this:
> > >> > >> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> > >> > >> >> To be honest I don't like that at all. You should never add or
> > >> remove
> > >> > >> >> anything to convert a time from one timezone to another.
> > >> > >> >>
> > >> > >> >> Time is always the same, it never can happen that you ever add
> > or
> > >> > remove
> > >> > >> >> anything to it. The only thing that changes is the timezone.
> Not
> > >> the
> > >> > >> time.
> > >> > >> >> That means if you want to transfer 5pm from CEST to NZD.
> > >> > >> >> The right Java class to do that is: java.util.Timezone.
> > >> > >> >>
> > >> > >> >> So something like:
> > >> > >> >> Calendar cal = Calendar.getInstance();
> > >> > >> >> cal.setTimeZone(timezone); // which is then a
> java.util.Timezone
> > >> > >> >>
> > >> > >> >> However if the Calendar UI does _not_ support
> > java.util.Calendar we
> > >> > >> have a
> > >> > >> >> problem.
> > >> > >> >>
> > >> > >> >> For instance the method "onSubmit" this "Date" (start) in
> which
> > >> > timezone
> > >> > >> >> will it be? Server's ? Client's? Browser settings? User
> profile
> > ?
> > >> > What
> > >> > >> is
> > >> > >> >> it ?
> > >> > >> >>
> > >> > >> >> Try to think through this use case for example: Anybody can
> > >> configure
> > >> > >> that
> > >> > >> >> his user profile is in Sydney, Australia Daylight time, but
> > >> > according to
> > >> > >> >> his browser/Operating system he would be currently in Berlin,
> > >> Europe
> > >> > >> >> central time, and the server itself is in New York(I think
> > America
> > >> > >> Eastern
> > >> > >> >> Daylight Time).
> > >> > >> >> So what time is the meeting scheduled if he adds a new event
> at
> > >> 3pm?
> > >> > Is
> > >> > >> it
> > >> > >> >> 3pm Paris, 3pm New York or 3pm Sydney ?
> > >> > >> >>
> > >> > >> >> There is really no way to add a little bit of time here and
> > there
> > >> and
> > >> > >> then
> > >> > >> >> remove it somewhere else: You really need to know exactly what
> > >> > timezone
> > >> > >> you
> > >> > >> >> are currently handling.
> > >> > >> >>
> > >> > >> >> 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
> > >> > >>
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > 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
> > >>
> > >
> > >
> > >
> > > --
> > > 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: Is the Calendar UI timezone safe ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
This might be one way, however we should try to avoid "adding" or
"removing" time.
The time itself never changes. Its just the timezone. The probably best
class for that is java.util.Calendar and java.util.Timezone.
However we can discuss this issue for ages.
You really have to go into the details and test and verify all those use
cases.
So lets do that and discuss then the next steps.
Sebastian
2013/7/31 Alexei Fedotov <al...@gmail.com>
> AFAIU
> Maybe this is not the best way, yet one can use the following
> javascript method to calculate a time zone:
>
> > getTimezoneOffset()
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
> [1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
>
>
> On Wed, Jul 31, 2013 at 9:34 AM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
> > "Unfortunately there is no such thing as "browser timezone" :("
> > There is the operating system timezone.
> > And when you pass the date object via JavaScript to the server, the
> > question is what timezone this date represents.
> > For instance if the operating system has the timezone NZDT those
> Date/Times
> > will be transfered with a Date Object that has NZDT time.
> > If the user has configured his Calendar UI to show in CEST time, the
> wrong
> > time will be transfer when the user submits for instance 5pm. The browser
> > will submit it as 5pm NZDT but the user meant 5pm CEST.
> >
> > I have been mucking around with that stuff for weeks. Translating server
> > and client side times is not that hard.
> > It all seems to work fine.
> > But you will realize very soon that users will want to configure
> different
> > timezones for their OpenMeetings user profile then from their device.
> > And this is where the huzzle starts :0
> >
> > Sebastian
> >
> >
> > 2013/7/31 Maxim Solodovnik <so...@gmail.com>
> >
> >> Unfortunately there is no such thing as "browser timezone" :(
> >>
> >> According to my observations all events in calendar are displayed as
> >> expected.
> >> According to Google FullCalendar being used as our JS library is TZ
> safe if
> >> TZ is stored somewhere (If I'm not mistaken we are storing TZ for every
> >> event)
> >>
> >> I would ask Irina to test it :) or maybe to write test plan :)
> >>
> >> Currently I feel this version works as good as 2.1.1, need to finish and
> >> release it :)
> >>
> >>
> >> On Tue, Jul 30, 2013 at 8:19 PM, Alexei Fedotov <
> alexei.fedotov@gmail.com
> >> >wrote:
> >>
> >> > If a browser timezone is not set, one can use a server time zone
> >> > assuming people work locally. For some countries like Germany which
> >> > are in one timezone this works well for national wide conferences.
> >> > --
> >> > With best regards / с наилучшими пожеланиями,
> >> > Alexei Fedotov / Алексей Федотов,
> >> > http://dataved.ru/
> >> > +7 916 562 8095
> >> >
> >> > [1] Start using Apache Openmeetings today,
> >> http://openmeetings.apache.org/
> >> > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> >> > [3] Join Alexei Fedotov @facebook,
> http://www.facebook.com/openmeetings
> >> >
> >> >
> >> > On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
> >> > <se...@gmail.com> wrote:
> >> > > What kind of "default" timezone will be used, is another question
> from
> >> my
> >> > > point of view.
> >> > >
> >> > > Still the calendar has to be able to show the UI in whatever
> timezone
> >> the
> >> > > user selects in his profile settings. Independent what is
> configured in
> >> > the
> >> > > Browser and Operating system and on the server side. And currently
> I am
> >> > not
> >> > > sure if we can do that.
> >> > > There are a number of use cases we have to play through to check
> that
> >> > out.
> >> > > Also for instance:
> >> > > 1) The invitation hash generated are only valid during the time of
> the
> >> > > meeting
> >> > > 2) And for instance when you use that link you will see a popup in
> the
> >> > > conference room that shows the start and end date of the meeting.
> >> > > Both is relevant to have the correct timezones set. Or what happens
> if
> >> > you
> >> > > change the meeting time in the Calendar UI, will the update email
> >> > correctly
> >> > > include new hashs with updated times in the correct timezone (or
> maybe
> >> it
> >> > > edit the existing ones, I am not sure at this moment what we had
> >> > > implemented in OpenMeetings 2.x.)?
> >> > >
> >> > > Some of those functionality will be simply re-used from OpenMeetings
> >> 2.x.
> >> > > But the UI somehow has to reflect that or we will not only re-code
> the
> >> > > client side but also the server side.
> >> > >
> >> > >
> >> > > Sebastian
> >> > >
> >> > >
> >> > > 2013/7/30 Alexei Fedotov <al...@gmail.com>
> >> > >
> >> > >> Hello Sebastian,
> >> > >>
> >> > >> AFAIU the timezone code should take browser locale into account,
> thus
> >> > >> it should be client side javascript at the first place.
> >> > >>
> >> > >> This means unless you reconfigure your notebook from Germany to
> Sidney
> >> > >> time you never get meetings in the proper time. My phone already
> makes
> >> > >> an automatic switch based on carrier's data - this will be
> propagated
> >> > >> to computers sooner or later.
> >> > >>
> >> > >> Vasily, what do you think?
> >> > >> --
> >> > >> With best regards / с наилучшими пожеланиями,
> >> > >> Alexei Fedotov / Алексей Федотов,
> >> > >> http://dataved.ru/
> >> > >> +7 916 562 8095
> >> > >>
> >> > >> [1] Start using Apache Openmeetings today,
> >> > http://openmeetings.apache.org/
> >> > >> [2] Join Alexei Fedotov @linkedin,
> http://ru.linkedin.com/in/dataved/
> >> > >> [3] Join Alexei Fedotov @facebook,
> >> http://www.facebook.com/openmeetings
> >> > >>
> >> > >>
> >> > >> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
> >> > >> <se...@gmail.com> wrote:
> >> > >> > I will try to make some tests here.
> >> > >> >
> >> > >> > I just wonder: Is everybody involved clear with that design and
> what
> >> > >> needs
> >> > >> > to be done?
> >> > >> >
> >> > >> > Beeing timezone safe is a major criteria for the Calendar UI to
> be
> >> > >> > released. It was already an annoying thing that raised issues
> over
> >> > years
> >> > >> in
> >> > >> > OpenMeetings until it got fixed in the past :)
> >> > >> >
> >> > >> > Sebastian
> >> > >> >
> >> > >> >
> >> > >> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> >> > >> >
> >> > >> >> I have a question around the jQuery Plugin for the Calendar UI
> that
> >> > we
> >> > >> are
> >> > >> >> using now.
> >> > >> >>
> >> > >> >> I don't see how this will exactly handle time zones.
> >> > >> >>
> >> > >> >> From what I can see in the source code is that it is using
> heavily
> >> > the
> >> > >> >> java.util.Date to set and get the date. java.util.Date does not
> >> > handle
> >> > >> >> timezones at all. The right clas would be java.util.Calendar.
> >> > >> >>
> >> > >> >> I don't know if the concept of the timezone handling was clear
> to
> >> > >> >> everybody so far:
> >> > >> >> Database fields don't care about timezones. That is why in the
> >> > >> >> table/entity "Appointment" the Date is simply a java.util.Date
> >> (not a
> >> > >> >> timezone safe java.util.Calendar). Cause if you would use
> >> > >> >> "java.util.Calendar" the database would simply cut away the
> >> timezone
> >> > >> info!
> >> > >> >> That is why it is Date and not Calendar. Databases simply don't
> >> care
> >> > >> about
> >> > >> >> timezones. A database field "datetime" is simply YYYY-MM-DD
> >> HH:MM:SS
> >> > =>
> >> > >> and
> >> > >> >> no timezones.
> >> > >> >>
> >> > >> >> So the general message is: The date/time that is stored in the
> >> > database
> >> > >> is
> >> > >> >> always _in the local time of the server_ (or more correctly: In
> the
> >> > >> time of
> >> > >> >> the database server).
> >> > >> >> In general that does not really generate a problem, as long as
> you
> >> > know
> >> > >> >> this behavour.
> >> > >> >>
> >> > >> >>
> >> > >> >> However the end users of course often live in a completely
> >> different
> >> > >> >> timezone as the server, and also every user can set up their own
> >> > >> timezone
> >> > >> >> in their user profile. So the timezone of the browser not
> >> neccessarly
> >> > >> >> matches the user settings.
> >> > >> >>
> >> > >> >> I see a number of (FIXME) in the source code when it comes to
> the
> >> > date
> >> > >> >> timezone conversion.
> >> > >> >> Stuff like this:
> >> > >> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> >> > >> >> To be honest I don't like that at all. You should never add or
> >> remove
> >> > >> >> anything to convert a time from one timezone to another.
> >> > >> >>
> >> > >> >> Time is always the same, it never can happen that you ever add
> or
> >> > remove
> >> > >> >> anything to it. The only thing that changes is the timezone. Not
> >> the
> >> > >> time.
> >> > >> >> That means if you want to transfer 5pm from CEST to NZD.
> >> > >> >> The right Java class to do that is: java.util.Timezone.
> >> > >> >>
> >> > >> >> So something like:
> >> > >> >> Calendar cal = Calendar.getInstance();
> >> > >> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
> >> > >> >>
> >> > >> >> However if the Calendar UI does _not_ support
> java.util.Calendar we
> >> > >> have a
> >> > >> >> problem.
> >> > >> >>
> >> > >> >> For instance the method "onSubmit" this "Date" (start) in which
> >> > timezone
> >> > >> >> will it be? Server's ? Client's? Browser settings? User profile
> ?
> >> > What
> >> > >> is
> >> > >> >> it ?
> >> > >> >>
> >> > >> >> Try to think through this use case for example: Anybody can
> >> configure
> >> > >> that
> >> > >> >> his user profile is in Sydney, Australia Daylight time, but
> >> > according to
> >> > >> >> his browser/Operating system he would be currently in Berlin,
> >> Europe
> >> > >> >> central time, and the server itself is in New York(I think
> America
> >> > >> Eastern
> >> > >> >> Daylight Time).
> >> > >> >> So what time is the meeting scheduled if he adds a new event at
> >> 3pm?
> >> > Is
> >> > >> it
> >> > >> >> 3pm Paris, 3pm New York or 3pm Sydney ?
> >> > >> >>
> >> > >> >> There is really no way to add a little bit of time here and
> there
> >> and
> >> > >> then
> >> > >> >> remove it somewhere else: You really need to know exactly what
> >> > timezone
> >> > >> you
> >> > >> >> are currently handling.
> >> > >> >>
> >> > >> >> 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
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > 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
> >>
> >
> >
> >
> > --
> > 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: Is the Calendar UI timezone safe ?
Posted by Alexei Fedotov <al...@gmail.com>.
AFAIU
Maybe this is not the best way, yet one can use the following
javascript method to calculate a time zone:
> getTimezoneOffset()
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
[1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
[2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
[3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
On Wed, Jul 31, 2013 at 9:34 AM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> "Unfortunately there is no such thing as "browser timezone" :("
> There is the operating system timezone.
> And when you pass the date object via JavaScript to the server, the
> question is what timezone this date represents.
> For instance if the operating system has the timezone NZDT those Date/Times
> will be transfered with a Date Object that has NZDT time.
> If the user has configured his Calendar UI to show in CEST time, the wrong
> time will be transfer when the user submits for instance 5pm. The browser
> will submit it as 5pm NZDT but the user meant 5pm CEST.
>
> I have been mucking around with that stuff for weeks. Translating server
> and client side times is not that hard.
> It all seems to work fine.
> But you will realize very soon that users will want to configure different
> timezones for their OpenMeetings user profile then from their device.
> And this is where the huzzle starts :0
>
> Sebastian
>
>
> 2013/7/31 Maxim Solodovnik <so...@gmail.com>
>
>> Unfortunately there is no such thing as "browser timezone" :(
>>
>> According to my observations all events in calendar are displayed as
>> expected.
>> According to Google FullCalendar being used as our JS library is TZ safe if
>> TZ is stored somewhere (If I'm not mistaken we are storing TZ for every
>> event)
>>
>> I would ask Irina to test it :) or maybe to write test plan :)
>>
>> Currently I feel this version works as good as 2.1.1, need to finish and
>> release it :)
>>
>>
>> On Tue, Jul 30, 2013 at 8:19 PM, Alexei Fedotov <alexei.fedotov@gmail.com
>> >wrote:
>>
>> > If a browser timezone is not set, one can use a server time zone
>> > assuming people work locally. For some countries like Germany which
>> > are in one timezone this works well for national wide conferences.
>> > --
>> > With best regards / с наилучшими пожеланиями,
>> > Alexei Fedotov / Алексей Федотов,
>> > http://dataved.ru/
>> > +7 916 562 8095
>> >
>> > [1] Start using Apache Openmeetings today,
>> http://openmeetings.apache.org/
>> > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
>> > [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
>> >
>> >
>> > On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
>> > <se...@gmail.com> wrote:
>> > > What kind of "default" timezone will be used, is another question from
>> my
>> > > point of view.
>> > >
>> > > Still the calendar has to be able to show the UI in whatever timezone
>> the
>> > > user selects in his profile settings. Independent what is configured in
>> > the
>> > > Browser and Operating system and on the server side. And currently I am
>> > not
>> > > sure if we can do that.
>> > > There are a number of use cases we have to play through to check that
>> > out.
>> > > Also for instance:
>> > > 1) The invitation hash generated are only valid during the time of the
>> > > meeting
>> > > 2) And for instance when you use that link you will see a popup in the
>> > > conference room that shows the start and end date of the meeting.
>> > > Both is relevant to have the correct timezones set. Or what happens if
>> > you
>> > > change the meeting time in the Calendar UI, will the update email
>> > correctly
>> > > include new hashs with updated times in the correct timezone (or maybe
>> it
>> > > edit the existing ones, I am not sure at this moment what we had
>> > > implemented in OpenMeetings 2.x.)?
>> > >
>> > > Some of those functionality will be simply re-used from OpenMeetings
>> 2.x.
>> > > But the UI somehow has to reflect that or we will not only re-code the
>> > > client side but also the server side.
>> > >
>> > >
>> > > Sebastian
>> > >
>> > >
>> > > 2013/7/30 Alexei Fedotov <al...@gmail.com>
>> > >
>> > >> Hello Sebastian,
>> > >>
>> > >> AFAIU the timezone code should take browser locale into account, thus
>> > >> it should be client side javascript at the first place.
>> > >>
>> > >> This means unless you reconfigure your notebook from Germany to Sidney
>> > >> time you never get meetings in the proper time. My phone already makes
>> > >> an automatic switch based on carrier's data - this will be propagated
>> > >> to computers sooner or later.
>> > >>
>> > >> Vasily, what do you think?
>> > >> --
>> > >> With best regards / с наилучшими пожеланиями,
>> > >> Alexei Fedotov / Алексей Федотов,
>> > >> http://dataved.ru/
>> > >> +7 916 562 8095
>> > >>
>> > >> [1] Start using Apache Openmeetings today,
>> > http://openmeetings.apache.org/
>> > >> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
>> > >> [3] Join Alexei Fedotov @facebook,
>> http://www.facebook.com/openmeetings
>> > >>
>> > >>
>> > >> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
>> > >> <se...@gmail.com> wrote:
>> > >> > I will try to make some tests here.
>> > >> >
>> > >> > I just wonder: Is everybody involved clear with that design and what
>> > >> needs
>> > >> > to be done?
>> > >> >
>> > >> > Beeing timezone safe is a major criteria for the Calendar UI to be
>> > >> > released. It was already an annoying thing that raised issues over
>> > years
>> > >> in
>> > >> > OpenMeetings until it got fixed in the past :)
>> > >> >
>> > >> > Sebastian
>> > >> >
>> > >> >
>> > >> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
>> > >> >
>> > >> >> I have a question around the jQuery Plugin for the Calendar UI that
>> > we
>> > >> are
>> > >> >> using now.
>> > >> >>
>> > >> >> I don't see how this will exactly handle time zones.
>> > >> >>
>> > >> >> From what I can see in the source code is that it is using heavily
>> > the
>> > >> >> java.util.Date to set and get the date. java.util.Date does not
>> > handle
>> > >> >> timezones at all. The right clas would be java.util.Calendar.
>> > >> >>
>> > >> >> I don't know if the concept of the timezone handling was clear to
>> > >> >> everybody so far:
>> > >> >> Database fields don't care about timezones. That is why in the
>> > >> >> table/entity "Appointment" the Date is simply a java.util.Date
>> (not a
>> > >> >> timezone safe java.util.Calendar). Cause if you would use
>> > >> >> "java.util.Calendar" the database would simply cut away the
>> timezone
>> > >> info!
>> > >> >> That is why it is Date and not Calendar. Databases simply don't
>> care
>> > >> about
>> > >> >> timezones. A database field "datetime" is simply YYYY-MM-DD
>> HH:MM:SS
>> > =>
>> > >> and
>> > >> >> no timezones.
>> > >> >>
>> > >> >> So the general message is: The date/time that is stored in the
>> > database
>> > >> is
>> > >> >> always _in the local time of the server_ (or more correctly: In the
>> > >> time of
>> > >> >> the database server).
>> > >> >> In general that does not really generate a problem, as long as you
>> > know
>> > >> >> this behavour.
>> > >> >>
>> > >> >>
>> > >> >> However the end users of course often live in a completely
>> different
>> > >> >> timezone as the server, and also every user can set up their own
>> > >> timezone
>> > >> >> in their user profile. So the timezone of the browser not
>> neccessarly
>> > >> >> matches the user settings.
>> > >> >>
>> > >> >> I see a number of (FIXME) in the source code when it comes to the
>> > date
>> > >> >> timezone conversion.
>> > >> >> Stuff like this:
>> > >> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
>> > >> >> To be honest I don't like that at all. You should never add or
>> remove
>> > >> >> anything to convert a time from one timezone to another.
>> > >> >>
>> > >> >> Time is always the same, it never can happen that you ever add or
>> > remove
>> > >> >> anything to it. The only thing that changes is the timezone. Not
>> the
>> > >> time.
>> > >> >> That means if you want to transfer 5pm from CEST to NZD.
>> > >> >> The right Java class to do that is: java.util.Timezone.
>> > >> >>
>> > >> >> So something like:
>> > >> >> Calendar cal = Calendar.getInstance();
>> > >> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
>> > >> >>
>> > >> >> However if the Calendar UI does _not_ support java.util.Calendar we
>> > >> have a
>> > >> >> problem.
>> > >> >>
>> > >> >> For instance the method "onSubmit" this "Date" (start) in which
>> > timezone
>> > >> >> will it be? Server's ? Client's? Browser settings? User profile ?
>> > What
>> > >> is
>> > >> >> it ?
>> > >> >>
>> > >> >> Try to think through this use case for example: Anybody can
>> configure
>> > >> that
>> > >> >> his user profile is in Sydney, Australia Daylight time, but
>> > according to
>> > >> >> his browser/Operating system he would be currently in Berlin,
>> Europe
>> > >> >> central time, and the server itself is in New York(I think America
>> > >> Eastern
>> > >> >> Daylight Time).
>> > >> >> So what time is the meeting scheduled if he adds a new event at
>> 3pm?
>> > Is
>> > >> it
>> > >> >> 3pm Paris, 3pm New York or 3pm Sydney ?
>> > >> >>
>> > >> >> There is really no way to add a little bit of time here and there
>> and
>> > >> then
>> > >> >> remove it somewhere else: You really need to know exactly what
>> > timezone
>> > >> you
>> > >> >> are currently handling.
>> > >> >>
>> > >> >> 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
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > 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
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
Re: Is the Calendar UI timezone safe ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
"Unfortunately there is no such thing as "browser timezone" :("
There is the operating system timezone.
And when you pass the date object via JavaScript to the server, the
question is what timezone this date represents.
For instance if the operating system has the timezone NZDT those Date/Times
will be transfered with a Date Object that has NZDT time.
If the user has configured his Calendar UI to show in CEST time, the wrong
time will be transfer when the user submits for instance 5pm. The browser
will submit it as 5pm NZDT but the user meant 5pm CEST.
I have been mucking around with that stuff for weeks. Translating server
and client side times is not that hard.
It all seems to work fine.
But you will realize very soon that users will want to configure different
timezones for their OpenMeetings user profile then from their device.
And this is where the huzzle starts :0
Sebastian
2013/7/31 Maxim Solodovnik <so...@gmail.com>
> Unfortunately there is no such thing as "browser timezone" :(
>
> According to my observations all events in calendar are displayed as
> expected.
> According to Google FullCalendar being used as our JS library is TZ safe if
> TZ is stored somewhere (If I'm not mistaken we are storing TZ for every
> event)
>
> I would ask Irina to test it :) or maybe to write test plan :)
>
> Currently I feel this version works as good as 2.1.1, need to finish and
> release it :)
>
>
> On Tue, Jul 30, 2013 at 8:19 PM, Alexei Fedotov <alexei.fedotov@gmail.com
> >wrote:
>
> > If a browser timezone is not set, one can use a server time zone
> > assuming people work locally. For some countries like Germany which
> > are in one timezone this works well for national wide conferences.
> > --
> > With best regards / с наилучшими пожеланиями,
> > Alexei Fedotov / Алексей Федотов,
> > http://dataved.ru/
> > +7 916 562 8095
> >
> > [1] Start using Apache Openmeetings today,
> http://openmeetings.apache.org/
> > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> > [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
> >
> >
> > On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
> > <se...@gmail.com> wrote:
> > > What kind of "default" timezone will be used, is another question from
> my
> > > point of view.
> > >
> > > Still the calendar has to be able to show the UI in whatever timezone
> the
> > > user selects in his profile settings. Independent what is configured in
> > the
> > > Browser and Operating system and on the server side. And currently I am
> > not
> > > sure if we can do that.
> > > There are a number of use cases we have to play through to check that
> > out.
> > > Also for instance:
> > > 1) The invitation hash generated are only valid during the time of the
> > > meeting
> > > 2) And for instance when you use that link you will see a popup in the
> > > conference room that shows the start and end date of the meeting.
> > > Both is relevant to have the correct timezones set. Or what happens if
> > you
> > > change the meeting time in the Calendar UI, will the update email
> > correctly
> > > include new hashs with updated times in the correct timezone (or maybe
> it
> > > edit the existing ones, I am not sure at this moment what we had
> > > implemented in OpenMeetings 2.x.)?
> > >
> > > Some of those functionality will be simply re-used from OpenMeetings
> 2.x.
> > > But the UI somehow has to reflect that or we will not only re-code the
> > > client side but also the server side.
> > >
> > >
> > > Sebastian
> > >
> > >
> > > 2013/7/30 Alexei Fedotov <al...@gmail.com>
> > >
> > >> Hello Sebastian,
> > >>
> > >> AFAIU the timezone code should take browser locale into account, thus
> > >> it should be client side javascript at the first place.
> > >>
> > >> This means unless you reconfigure your notebook from Germany to Sidney
> > >> time you never get meetings in the proper time. My phone already makes
> > >> an automatic switch based on carrier's data - this will be propagated
> > >> to computers sooner or later.
> > >>
> > >> Vasily, what do you think?
> > >> --
> > >> With best regards / с наилучшими пожеланиями,
> > >> Alexei Fedotov / Алексей Федотов,
> > >> http://dataved.ru/
> > >> +7 916 562 8095
> > >>
> > >> [1] Start using Apache Openmeetings today,
> > http://openmeetings.apache.org/
> > >> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> > >> [3] Join Alexei Fedotov @facebook,
> http://www.facebook.com/openmeetings
> > >>
> > >>
> > >> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
> > >> <se...@gmail.com> wrote:
> > >> > I will try to make some tests here.
> > >> >
> > >> > I just wonder: Is everybody involved clear with that design and what
> > >> needs
> > >> > to be done?
> > >> >
> > >> > Beeing timezone safe is a major criteria for the Calendar UI to be
> > >> > released. It was already an annoying thing that raised issues over
> > years
> > >> in
> > >> > OpenMeetings until it got fixed in the past :)
> > >> >
> > >> > Sebastian
> > >> >
> > >> >
> > >> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> > >> >
> > >> >> I have a question around the jQuery Plugin for the Calendar UI that
> > we
> > >> are
> > >> >> using now.
> > >> >>
> > >> >> I don't see how this will exactly handle time zones.
> > >> >>
> > >> >> From what I can see in the source code is that it is using heavily
> > the
> > >> >> java.util.Date to set and get the date. java.util.Date does not
> > handle
> > >> >> timezones at all. The right clas would be java.util.Calendar.
> > >> >>
> > >> >> I don't know if the concept of the timezone handling was clear to
> > >> >> everybody so far:
> > >> >> Database fields don't care about timezones. That is why in the
> > >> >> table/entity "Appointment" the Date is simply a java.util.Date
> (not a
> > >> >> timezone safe java.util.Calendar). Cause if you would use
> > >> >> "java.util.Calendar" the database would simply cut away the
> timezone
> > >> info!
> > >> >> That is why it is Date and not Calendar. Databases simply don't
> care
> > >> about
> > >> >> timezones. A database field "datetime" is simply YYYY-MM-DD
> HH:MM:SS
> > =>
> > >> and
> > >> >> no timezones.
> > >> >>
> > >> >> So the general message is: The date/time that is stored in the
> > database
> > >> is
> > >> >> always _in the local time of the server_ (or more correctly: In the
> > >> time of
> > >> >> the database server).
> > >> >> In general that does not really generate a problem, as long as you
> > know
> > >> >> this behavour.
> > >> >>
> > >> >>
> > >> >> However the end users of course often live in a completely
> different
> > >> >> timezone as the server, and also every user can set up their own
> > >> timezone
> > >> >> in their user profile. So the timezone of the browser not
> neccessarly
> > >> >> matches the user settings.
> > >> >>
> > >> >> I see a number of (FIXME) in the source code when it comes to the
> > date
> > >> >> timezone conversion.
> > >> >> Stuff like this:
> > >> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> > >> >> To be honest I don't like that at all. You should never add or
> remove
> > >> >> anything to convert a time from one timezone to another.
> > >> >>
> > >> >> Time is always the same, it never can happen that you ever add or
> > remove
> > >> >> anything to it. The only thing that changes is the timezone. Not
> the
> > >> time.
> > >> >> That means if you want to transfer 5pm from CEST to NZD.
> > >> >> The right Java class to do that is: java.util.Timezone.
> > >> >>
> > >> >> So something like:
> > >> >> Calendar cal = Calendar.getInstance();
> > >> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
> > >> >>
> > >> >> However if the Calendar UI does _not_ support java.util.Calendar we
> > >> have a
> > >> >> problem.
> > >> >>
> > >> >> For instance the method "onSubmit" this "Date" (start) in which
> > timezone
> > >> >> will it be? Server's ? Client's? Browser settings? User profile ?
> > What
> > >> is
> > >> >> it ?
> > >> >>
> > >> >> Try to think through this use case for example: Anybody can
> configure
> > >> that
> > >> >> his user profile is in Sydney, Australia Daylight time, but
> > according to
> > >> >> his browser/Operating system he would be currently in Berlin,
> Europe
> > >> >> central time, and the server itself is in New York(I think America
> > >> Eastern
> > >> >> Daylight Time).
> > >> >> So what time is the meeting scheduled if he adds a new event at
> 3pm?
> > Is
> > >> it
> > >> >> 3pm Paris, 3pm New York or 3pm Sydney ?
> > >> >>
> > >> >> There is really no way to add a little bit of time here and there
> and
> > >> then
> > >> >> remove it somewhere else: You really need to know exactly what
> > timezone
> > >> you
> > >> >> are currently handling.
> > >> >>
> > >> >> 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
> > >>
> > >
> > >
> > >
> > > --
> > > 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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Is the Calendar UI timezone safe ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Unfortunately there is no such thing as "browser timezone" :(
According to my observations all events in calendar are displayed as
expected.
According to Google FullCalendar being used as our JS library is TZ safe if
TZ is stored somewhere (If I'm not mistaken we are storing TZ for every
event)
I would ask Irina to test it :) or maybe to write test plan :)
Currently I feel this version works as good as 2.1.1, need to finish and
release it :)
On Tue, Jul 30, 2013 at 8:19 PM, Alexei Fedotov <al...@gmail.com>wrote:
> If a browser timezone is not set, one can use a server time zone
> assuming people work locally. For some countries like Germany which
> are in one timezone this works well for national wide conferences.
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
> [1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
>
>
> On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
> > What kind of "default" timezone will be used, is another question from my
> > point of view.
> >
> > Still the calendar has to be able to show the UI in whatever timezone the
> > user selects in his profile settings. Independent what is configured in
> the
> > Browser and Operating system and on the server side. And currently I am
> not
> > sure if we can do that.
> > There are a number of use cases we have to play through to check that
> out.
> > Also for instance:
> > 1) The invitation hash generated are only valid during the time of the
> > meeting
> > 2) And for instance when you use that link you will see a popup in the
> > conference room that shows the start and end date of the meeting.
> > Both is relevant to have the correct timezones set. Or what happens if
> you
> > change the meeting time in the Calendar UI, will the update email
> correctly
> > include new hashs with updated times in the correct timezone (or maybe it
> > edit the existing ones, I am not sure at this moment what we had
> > implemented in OpenMeetings 2.x.)?
> >
> > Some of those functionality will be simply re-used from OpenMeetings 2.x.
> > But the UI somehow has to reflect that or we will not only re-code the
> > client side but also the server side.
> >
> >
> > Sebastian
> >
> >
> > 2013/7/30 Alexei Fedotov <al...@gmail.com>
> >
> >> Hello Sebastian,
> >>
> >> AFAIU the timezone code should take browser locale into account, thus
> >> it should be client side javascript at the first place.
> >>
> >> This means unless you reconfigure your notebook from Germany to Sidney
> >> time you never get meetings in the proper time. My phone already makes
> >> an automatic switch based on carrier's data - this will be propagated
> >> to computers sooner or later.
> >>
> >> Vasily, what do you think?
> >> --
> >> With best regards / с наилучшими пожеланиями,
> >> Alexei Fedotov / Алексей Федотов,
> >> http://dataved.ru/
> >> +7 916 562 8095
> >>
> >> [1] Start using Apache Openmeetings today,
> http://openmeetings.apache.org/
> >> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> >> [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
> >>
> >>
> >> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
> >> <se...@gmail.com> wrote:
> >> > I will try to make some tests here.
> >> >
> >> > I just wonder: Is everybody involved clear with that design and what
> >> needs
> >> > to be done?
> >> >
> >> > Beeing timezone safe is a major criteria for the Calendar UI to be
> >> > released. It was already an annoying thing that raised issues over
> years
> >> in
> >> > OpenMeetings until it got fixed in the past :)
> >> >
> >> > Sebastian
> >> >
> >> >
> >> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> >> >
> >> >> I have a question around the jQuery Plugin for the Calendar UI that
> we
> >> are
> >> >> using now.
> >> >>
> >> >> I don't see how this will exactly handle time zones.
> >> >>
> >> >> From what I can see in the source code is that it is using heavily
> the
> >> >> java.util.Date to set and get the date. java.util.Date does not
> handle
> >> >> timezones at all. The right clas would be java.util.Calendar.
> >> >>
> >> >> I don't know if the concept of the timezone handling was clear to
> >> >> everybody so far:
> >> >> Database fields don't care about timezones. That is why in the
> >> >> table/entity "Appointment" the Date is simply a java.util.Date (not a
> >> >> timezone safe java.util.Calendar). Cause if you would use
> >> >> "java.util.Calendar" the database would simply cut away the timezone
> >> info!
> >> >> That is why it is Date and not Calendar. Databases simply don't care
> >> about
> >> >> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS
> =>
> >> and
> >> >> no timezones.
> >> >>
> >> >> So the general message is: The date/time that is stored in the
> database
> >> is
> >> >> always _in the local time of the server_ (or more correctly: In the
> >> time of
> >> >> the database server).
> >> >> In general that does not really generate a problem, as long as you
> know
> >> >> this behavour.
> >> >>
> >> >>
> >> >> However the end users of course often live in a completely different
> >> >> timezone as the server, and also every user can set up their own
> >> timezone
> >> >> in their user profile. So the timezone of the browser not neccessarly
> >> >> matches the user settings.
> >> >>
> >> >> I see a number of (FIXME) in the source code when it comes to the
> date
> >> >> timezone conversion.
> >> >> Stuff like this:
> >> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> >> >> To be honest I don't like that at all. You should never add or remove
> >> >> anything to convert a time from one timezone to another.
> >> >>
> >> >> Time is always the same, it never can happen that you ever add or
> remove
> >> >> anything to it. The only thing that changes is the timezone. Not the
> >> time.
> >> >> That means if you want to transfer 5pm from CEST to NZD.
> >> >> The right Java class to do that is: java.util.Timezone.
> >> >>
> >> >> So something like:
> >> >> Calendar cal = Calendar.getInstance();
> >> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
> >> >>
> >> >> However if the Calendar UI does _not_ support java.util.Calendar we
> >> have a
> >> >> problem.
> >> >>
> >> >> For instance the method "onSubmit" this "Date" (start) in which
> timezone
> >> >> will it be? Server's ? Client's? Browser settings? User profile ?
> What
> >> is
> >> >> it ?
> >> >>
> >> >> Try to think through this use case for example: Anybody can configure
> >> that
> >> >> his user profile is in Sydney, Australia Daylight time, but
> according to
> >> >> his browser/Operating system he would be currently in Berlin, Europe
> >> >> central time, and the server itself is in New York(I think America
> >> Eastern
> >> >> Daylight Time).
> >> >> So what time is the meeting scheduled if he adds a new event at 3pm?
> Is
> >> it
> >> >> 3pm Paris, 3pm New York or 3pm Sydney ?
> >> >>
> >> >> There is really no way to add a little bit of time here and there and
> >> then
> >> >> remove it somewhere else: You really need to know exactly what
> timezone
> >> you
> >> >> are currently handling.
> >> >>
> >> >> 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
> >>
> >
> >
> >
> > --
> > 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: Is the Calendar UI timezone safe ?
Posted by Alexei Fedotov <al...@gmail.com>.
If a browser timezone is not set, one can use a server time zone
assuming people work locally. For some countries like Germany which
are in one timezone this works well for national wide conferences.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
[1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
[2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
[3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
On Tue, Jul 30, 2013 at 3:40 PM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> What kind of "default" timezone will be used, is another question from my
> point of view.
>
> Still the calendar has to be able to show the UI in whatever timezone the
> user selects in his profile settings. Independent what is configured in the
> Browser and Operating system and on the server side. And currently I am not
> sure if we can do that.
> There are a number of use cases we have to play through to check that out.
> Also for instance:
> 1) The invitation hash generated are only valid during the time of the
> meeting
> 2) And for instance when you use that link you will see a popup in the
> conference room that shows the start and end date of the meeting.
> Both is relevant to have the correct timezones set. Or what happens if you
> change the meeting time in the Calendar UI, will the update email correctly
> include new hashs with updated times in the correct timezone (or maybe it
> edit the existing ones, I am not sure at this moment what we had
> implemented in OpenMeetings 2.x.)?
>
> Some of those functionality will be simply re-used from OpenMeetings 2.x.
> But the UI somehow has to reflect that or we will not only re-code the
> client side but also the server side.
>
>
> Sebastian
>
>
> 2013/7/30 Alexei Fedotov <al...@gmail.com>
>
>> Hello Sebastian,
>>
>> AFAIU the timezone code should take browser locale into account, thus
>> it should be client side javascript at the first place.
>>
>> This means unless you reconfigure your notebook from Germany to Sidney
>> time you never get meetings in the proper time. My phone already makes
>> an automatic switch based on carrier's data - this will be propagated
>> to computers sooner or later.
>>
>> Vasily, what do you think?
>> --
>> With best regards / с наилучшими пожеланиями,
>> Alexei Fedotov / Алексей Федотов,
>> http://dataved.ru/
>> +7 916 562 8095
>>
>> [1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
>> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
>> [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
>>
>>
>> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
>> <se...@gmail.com> wrote:
>> > I will try to make some tests here.
>> >
>> > I just wonder: Is everybody involved clear with that design and what
>> needs
>> > to be done?
>> >
>> > Beeing timezone safe is a major criteria for the Calendar UI to be
>> > released. It was already an annoying thing that raised issues over years
>> in
>> > OpenMeetings until it got fixed in the past :)
>> >
>> > Sebastian
>> >
>> >
>> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
>> >
>> >> I have a question around the jQuery Plugin for the Calendar UI that we
>> are
>> >> using now.
>> >>
>> >> I don't see how this will exactly handle time zones.
>> >>
>> >> From what I can see in the source code is that it is using heavily the
>> >> java.util.Date to set and get the date. java.util.Date does not handle
>> >> timezones at all. The right clas would be java.util.Calendar.
>> >>
>> >> I don't know if the concept of the timezone handling was clear to
>> >> everybody so far:
>> >> Database fields don't care about timezones. That is why in the
>> >> table/entity "Appointment" the Date is simply a java.util.Date (not a
>> >> timezone safe java.util.Calendar). Cause if you would use
>> >> "java.util.Calendar" the database would simply cut away the timezone
>> info!
>> >> That is why it is Date and not Calendar. Databases simply don't care
>> about
>> >> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS =>
>> and
>> >> no timezones.
>> >>
>> >> So the general message is: The date/time that is stored in the database
>> is
>> >> always _in the local time of the server_ (or more correctly: In the
>> time of
>> >> the database server).
>> >> In general that does not really generate a problem, as long as you know
>> >> this behavour.
>> >>
>> >>
>> >> However the end users of course often live in a completely different
>> >> timezone as the server, and also every user can set up their own
>> timezone
>> >> in their user profile. So the timezone of the browser not neccessarly
>> >> matches the user settings.
>> >>
>> >> I see a number of (FIXME) in the source code when it comes to the date
>> >> timezone conversion.
>> >> Stuff like this:
>> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
>> >> To be honest I don't like that at all. You should never add or remove
>> >> anything to convert a time from one timezone to another.
>> >>
>> >> Time is always the same, it never can happen that you ever add or remove
>> >> anything to it. The only thing that changes is the timezone. Not the
>> time.
>> >> That means if you want to transfer 5pm from CEST to NZD.
>> >> The right Java class to do that is: java.util.Timezone.
>> >>
>> >> So something like:
>> >> Calendar cal = Calendar.getInstance();
>> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
>> >>
>> >> However if the Calendar UI does _not_ support java.util.Calendar we
>> have a
>> >> problem.
>> >>
>> >> For instance the method "onSubmit" this "Date" (start) in which timezone
>> >> will it be? Server's ? Client's? Browser settings? User profile ? What
>> is
>> >> it ?
>> >>
>> >> Try to think through this use case for example: Anybody can configure
>> that
>> >> his user profile is in Sydney, Australia Daylight time, but according to
>> >> his browser/Operating system he would be currently in Berlin, Europe
>> >> central time, and the server itself is in New York(I think America
>> Eastern
>> >> Daylight Time).
>> >> So what time is the meeting scheduled if he adds a new event at 3pm? Is
>> it
>> >> 3pm Paris, 3pm New York or 3pm Sydney ?
>> >>
>> >> There is really no way to add a little bit of time here and there and
>> then
>> >> remove it somewhere else: You really need to know exactly what timezone
>> you
>> >> are currently handling.
>> >>
>> >> 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
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
Re: Is the Calendar UI timezone safe ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
What kind of "default" timezone will be used, is another question from my
point of view.
Still the calendar has to be able to show the UI in whatever timezone the
user selects in his profile settings. Independent what is configured in the
Browser and Operating system and on the server side. And currently I am not
sure if we can do that.
There are a number of use cases we have to play through to check that out.
Also for instance:
1) The invitation hash generated are only valid during the time of the
meeting
2) And for instance when you use that link you will see a popup in the
conference room that shows the start and end date of the meeting.
Both is relevant to have the correct timezones set. Or what happens if you
change the meeting time in the Calendar UI, will the update email correctly
include new hashs with updated times in the correct timezone (or maybe it
edit the existing ones, I am not sure at this moment what we had
implemented in OpenMeetings 2.x.)?
Some of those functionality will be simply re-used from OpenMeetings 2.x.
But the UI somehow has to reflect that or we will not only re-code the
client side but also the server side.
Sebastian
2013/7/30 Alexei Fedotov <al...@gmail.com>
> Hello Sebastian,
>
> AFAIU the timezone code should take browser locale into account, thus
> it should be client side javascript at the first place.
>
> This means unless you reconfigure your notebook from Germany to Sidney
> time you never get meetings in the proper time. My phone already makes
> an automatic switch based on carrier's data - this will be propagated
> to computers sooner or later.
>
> Vasily, what do you think?
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
> [1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
> [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
> [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
>
>
> On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
> <se...@gmail.com> wrote:
> > I will try to make some tests here.
> >
> > I just wonder: Is everybody involved clear with that design and what
> needs
> > to be done?
> >
> > Beeing timezone safe is a major criteria for the Calendar UI to be
> > released. It was already an annoying thing that raised issues over years
> in
> > OpenMeetings until it got fixed in the past :)
> >
> > Sebastian
> >
> >
> > 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> >
> >> I have a question around the jQuery Plugin for the Calendar UI that we
> are
> >> using now.
> >>
> >> I don't see how this will exactly handle time zones.
> >>
> >> From what I can see in the source code is that it is using heavily the
> >> java.util.Date to set and get the date. java.util.Date does not handle
> >> timezones at all. The right clas would be java.util.Calendar.
> >>
> >> I don't know if the concept of the timezone handling was clear to
> >> everybody so far:
> >> Database fields don't care about timezones. That is why in the
> >> table/entity "Appointment" the Date is simply a java.util.Date (not a
> >> timezone safe java.util.Calendar). Cause if you would use
> >> "java.util.Calendar" the database would simply cut away the timezone
> info!
> >> That is why it is Date and not Calendar. Databases simply don't care
> about
> >> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS =>
> and
> >> no timezones.
> >>
> >> So the general message is: The date/time that is stored in the database
> is
> >> always _in the local time of the server_ (or more correctly: In the
> time of
> >> the database server).
> >> In general that does not really generate a problem, as long as you know
> >> this behavour.
> >>
> >>
> >> However the end users of course often live in a completely different
> >> timezone as the server, and also every user can set up their own
> timezone
> >> in their user profile. So the timezone of the browser not neccessarly
> >> matches the user settings.
> >>
> >> I see a number of (FIXME) in the source code when it comes to the date
> >> timezone conversion.
> >> Stuff like this:
> >> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> >> To be honest I don't like that at all. You should never add or remove
> >> anything to convert a time from one timezone to another.
> >>
> >> Time is always the same, it never can happen that you ever add or remove
> >> anything to it. The only thing that changes is the timezone. Not the
> time.
> >> That means if you want to transfer 5pm from CEST to NZD.
> >> The right Java class to do that is: java.util.Timezone.
> >>
> >> So something like:
> >> Calendar cal = Calendar.getInstance();
> >> cal.setTimeZone(timezone); // which is then a java.util.Timezone
> >>
> >> However if the Calendar UI does _not_ support java.util.Calendar we
> have a
> >> problem.
> >>
> >> For instance the method "onSubmit" this "Date" (start) in which timezone
> >> will it be? Server's ? Client's? Browser settings? User profile ? What
> is
> >> it ?
> >>
> >> Try to think through this use case for example: Anybody can configure
> that
> >> his user profile is in Sydney, Australia Daylight time, but according to
> >> his browser/Operating system he would be currently in Berlin, Europe
> >> central time, and the server itself is in New York(I think America
> Eastern
> >> Daylight Time).
> >> So what time is the meeting scheduled if he adds a new event at 3pm? Is
> it
> >> 3pm Paris, 3pm New York or 3pm Sydney ?
> >>
> >> There is really no way to add a little bit of time here and there and
> then
> >> remove it somewhere else: You really need to know exactly what timezone
> you
> >> are currently handling.
> >>
> >> 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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Is the Calendar UI timezone safe ?
Posted by Alexei Fedotov <al...@gmail.com>.
Hello Sebastian,
AFAIU the timezone code should take browser locale into account, thus
it should be client side javascript at the first place.
This means unless you reconfigure your notebook from Germany to Sidney
time you never get meetings in the proper time. My phone already makes
an automatic switch based on carrier's data - this will be propagated
to computers sooner or later.
Vasily, what do you think?
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
[1] Start using Apache Openmeetings today, http://openmeetings.apache.org/
[2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/
[3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings
On Tue, Jul 30, 2013 at 2:11 PM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> I will try to make some tests here.
>
> I just wonder: Is everybody involved clear with that design and what needs
> to be done?
>
> Beeing timezone safe is a major criteria for the Calendar UI to be
> released. It was already an annoying thing that raised issues over years in
> OpenMeetings until it got fixed in the past :)
>
> Sebastian
>
>
> 2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
>
>> I have a question around the jQuery Plugin for the Calendar UI that we are
>> using now.
>>
>> I don't see how this will exactly handle time zones.
>>
>> From what I can see in the source code is that it is using heavily the
>> java.util.Date to set and get the date. java.util.Date does not handle
>> timezones at all. The right clas would be java.util.Calendar.
>>
>> I don't know if the concept of the timezone handling was clear to
>> everybody so far:
>> Database fields don't care about timezones. That is why in the
>> table/entity "Appointment" the Date is simply a java.util.Date (not a
>> timezone safe java.util.Calendar). Cause if you would use
>> "java.util.Calendar" the database would simply cut away the timezone info!
>> That is why it is Date and not Calendar. Databases simply don't care about
>> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS => and
>> no timezones.
>>
>> So the general message is: The date/time that is stored in the database is
>> always _in the local time of the server_ (or more correctly: In the time of
>> the database server).
>> In general that does not really generate a problem, as long as you know
>> this behavour.
>>
>>
>> However the end users of course often live in a completely different
>> timezone as the server, and also every user can set up their own timezone
>> in their user profile. So the timezone of the browser not neccessarly
>> matches the user settings.
>>
>> I see a number of (FIXME) in the source code when it comes to the date
>> timezone conversion.
>> Stuff like this:
>> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
>> To be honest I don't like that at all. You should never add or remove
>> anything to convert a time from one timezone to another.
>>
>> Time is always the same, it never can happen that you ever add or remove
>> anything to it. The only thing that changes is the timezone. Not the time.
>> That means if you want to transfer 5pm from CEST to NZD.
>> The right Java class to do that is: java.util.Timezone.
>>
>> So something like:
>> Calendar cal = Calendar.getInstance();
>> cal.setTimeZone(timezone); // which is then a java.util.Timezone
>>
>> However if the Calendar UI does _not_ support java.util.Calendar we have a
>> problem.
>>
>> For instance the method "onSubmit" this "Date" (start) in which timezone
>> will it be? Server's ? Client's? Browser settings? User profile ? What is
>> it ?
>>
>> Try to think through this use case for example: Anybody can configure that
>> his user profile is in Sydney, Australia Daylight time, but according to
>> his browser/Operating system he would be currently in Berlin, Europe
>> central time, and the server itself is in New York(I think America Eastern
>> Daylight Time).
>> So what time is the meeting scheduled if he adds a new event at 3pm? Is it
>> 3pm Paris, 3pm New York or 3pm Sydney ?
>>
>> There is really no way to add a little bit of time here and there and then
>> remove it somewhere else: You really need to know exactly what timezone you
>> are currently handling.
>>
>> 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: Is the Calendar UI timezone safe ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
I will try to make some tests here.
I just wonder: Is everybody involved clear with that design and what needs
to be done?
Beeing timezone safe is a major criteria for the Calendar UI to be
released. It was already an annoying thing that raised issues over years in
OpenMeetings until it got fixed in the past :)
Sebastian
2013/7/27 seba.wagner@gmail.com <se...@gmail.com>
> I have a question around the jQuery Plugin for the Calendar UI that we are
> using now.
>
> I don't see how this will exactly handle time zones.
>
> From what I can see in the source code is that it is using heavily the
> java.util.Date to set and get the date. java.util.Date does not handle
> timezones at all. The right clas would be java.util.Calendar.
>
> I don't know if the concept of the timezone handling was clear to
> everybody so far:
> Database fields don't care about timezones. That is why in the
> table/entity "Appointment" the Date is simply a java.util.Date (not a
> timezone safe java.util.Calendar). Cause if you would use
> "java.util.Calendar" the database would simply cut away the timezone info!
> That is why it is Date and not Calendar. Databases simply don't care about
> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS => and
> no timezones.
>
> So the general message is: The date/time that is stored in the database is
> always _in the local time of the server_ (or more correctly: In the time of
> the database server).
> In general that does not really generate a problem, as long as you know
> this behavour.
>
>
> However the end users of course often live in a completely different
> timezone as the server, and also every user can set up their own timezone
> in their user profile. So the timezone of the browser not neccessarly
> matches the user settings.
>
> I see a number of (FIXME) in the source code when it comes to the date
> timezone conversion.
> Stuff like this:
> cal.add(java.util.Calendar.MILLISECOND, (int)delta); //FIXME?
> To be honest I don't like that at all. You should never add or remove
> anything to convert a time from one timezone to another.
>
> Time is always the same, it never can happen that you ever add or remove
> anything to it. The only thing that changes is the timezone. Not the time.
> That means if you want to transfer 5pm from CEST to NZD.
> The right Java class to do that is: java.util.Timezone.
>
> So something like:
> Calendar cal = Calendar.getInstance();
> cal.setTimeZone(timezone); // which is then a java.util.Timezone
>
> However if the Calendar UI does _not_ support java.util.Calendar we have a
> problem.
>
> For instance the method "onSubmit" this "Date" (start) in which timezone
> will it be? Server's ? Client's? Browser settings? User profile ? What is
> it ?
>
> Try to think through this use case for example: Anybody can configure that
> his user profile is in Sydney, Australia Daylight time, but according to
> his browser/Operating system he would be currently in Berlin, Europe
> central time, and the server itself is in New York(I think America Eastern
> Daylight Time).
> So what time is the meeting scheduled if he adds a new event at 3pm? Is it
> 3pm Paris, 3pm New York or 3pm Sydney ?
>
> There is really no way to add a little bit of time here and there and then
> remove it somewhere else: You really need to know exactly what timezone you
> are currently handling.
>
> 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