openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <>
Subject Re: Is the Calendar UI timezone safe ?
Date Tue, 30 Jul 2013 08:15:28 GMT
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 / Алексей Федотов,
+7 916 562 8095

[1] Start using Apache Openmeetings today,
[2] Join Alexei Fedotov @linkedin,
[3] Join Alexei Fedotov @facebook,

On Tue, Jul 30, 2013 at 2:11 PM,
<> 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 <>
>> 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
> --
> Sebastian Wagner

View raw message