Mailing-List: contact dev-help@openmeetings.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openmeetings.apache.org
Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com
 designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACeMiA-ecifCQoBRLVbx-ekadB1XVKZ0znYp4PmYs=qWh5i5cA@mail.gmail.com>
References: 
 <CACeMiA8U1F=mhu4Ke2nH_zwJh3bKuYF3Ey3Ezx-FcpknAmGS1g@mail.gmail.com>
 <CACeMiA-ecifCQoBRLVbx-ekadB1XVKZ0znYp4PmYs=qWh5i5cA@mail.gmail.com>
From: Alexei Fedotov <alexei.fedotov@gmail.com>
Date: Tue, 30 Jul 2013 15:15:28 +0700
Message-ID: 
 <CAGc_3jHQ9FG-3mxkEcChANpCc7-nF-n1ROeJQa1XP9k3QUkQTQ@mail.gmail.com>
Subject: Re: Is the Calendar UI timezone safe ?
To: dev <dev@openmeetings.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 / =D1=81 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=
=D0=BC=D0=B8 =D0=BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=
=D0=B8,
Alexei Fedotov / =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B5=D0=B9 =D0=A4=D0=B5=D0=
=B4=D0=BE=D1=82=D0=BE=D0=B2,
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
<seba.wagner@gmail.com> wrote:
> I will try to make some tests here.
>
> I just wonder: Is everybody involved clear with that design and what need=
s
> 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 <seba.wagner@gmail.com>
>
>> I have a question around the jQuery Plugin for the Calendar UI that we a=
re
>> 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 inf=
o!
>> That is why it is Date and not Calendar. Databases simply don't care abo=
ut
>> timezones. A database field "datetime" is simply YYYY-MM-DD HH:MM:SS =3D=
> 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 timezon=
e
>> 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 tim=
e.
>> 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 =3D 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 i=
s
>> it ?
>>
>> Try to think through this use case for example: Anybody can configure th=
at
>> 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 Easte=
rn
>> 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 th=
en
>> 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