My vote is for Alternative 2.
Vasiliy
On 09.08.2013 14:24, seba.wag...@gmail.com wrote:
So probably we can put this up for a vote?
The only alternative I see as a short term fix is to overwrite the users
"OmTimeZone" with the current timezone of the browser.
Alternative 1:
Short term fix, default OmTimeZone to current timezone in browser,
overwrite everytime the user logs in (Estimated 1-2 weeks of work)
Alternative 2:
Rewrite and refactor to get rid of entire OmTimeZone (as described in
attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt)
(Estimated 1-2 months of work)
The effort estimates are including time that is needed for fixing bugs and
do the testing.
Vote for 1 if you like to see this implemented as part of OpenMeetings
3.0.0, vote for Alternative 2 if you want to see this implemented as part
of OpenMeetings 3.0.0.
Thanks,
Sebastian
2013/8/8 seba.wag...@gmail.com <seba.wag...@gmail.com>
That is the major question.
Basically status now is that the Calendar UI is not ready to be released.
The UI is simply not working when your browser timezone is different from
the timezone in your OpenMeetings profile.
So either we can do the proposed fixes around getting rid of the
OmTimeZone completely or we try to do some kind of workaround in
OpenMeetings 3.0.0 and do the refactoring later.
Sebastian
2013/8/7 Maxim Solodovnik <solomax...@gmail.com>
Can we define any useful JUnit tests so that we don't need to do so
much manual testing ?
I believe so, but what version will be affected with this change? 3.0.0 or
3.1.0?
On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com <
seba.wag...@gmail.com
wrote:
"I would default server time zone to the time zone of the server.
It is up to admin to set it to the different value."
ok
"Additionally Appointment, I guess."
Nope, Appointment does not have timezone information. The start/end
date of
the appointment is always in the server time zone. Actually _an_
date/time
that is stored is always the server time.
We only need timezone information when we need to display that time for
any
_user_ to generate a localized representation of the date/time.
For instance an Appointment can be 8am GMT but for one user 1am
GMT/Berlin
should be displayed as 6pm NZDT/Auckland and for yet another
MeetingMember
it has to be displayed as 2am EDT/New York.
So from my point of view the User, MeetingMember and Invitations Entity
are
the right place. And that is already as it is now. So you can replace
OmTimeZone in all those classes with the new attribute that stored the
timezone.
Can we define any useful JUnit tests so that we don't need to do so much
manual testing ?
Sebastian
2013/8/7 Maxim Solodovnik <solomax...@gmail.com>
I would default server time zone to the time zone of the server.
It is up to admin to set it to the different value.
On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com <
seba.wag...@gmail.com> wrote:
I basically don't mind about the component in the UI. I just thought
initially that 650 in a combobox is too much.
However it does not seem to be an issue for the UI as such.
My basic question is what we use as default: Do we default to the
server
timezone or to the client site user timezone ?
Sebastian
2013/8/7 Maxim Solodovnik <solomax...@gmail.com>
The correct URL is http://timezonepicker.com/
On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <
solomax...@gmail.com
wrote:
I believe we can use something like this:
https://timezonepicker.com
(sources are here:
https://github.com/quicksketch/timezonepicker)
The only issues I can see right now:
1) it has no License set in the moment (
https://github.com/quicksketch/timezonepicker/issues/2)
2) It last updated 9 months ago
So maybe additional googling is required :)
On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com <
seba.wag...@gmail.com> wrote:
One thing that is not on our list now is the default timezone
of
the
server.
Currently when you install OpenMeetings you choose a timezone.
The questions are:
1) Where do we populate the timezones from in that list,
displaying
650
timezones of java.util.Timezone is not practical
2) If we default that timezone to some value, what shall it
be?
The
timezone of the server or the timezone of the client browser?
=> In theory this default timezone is used whenever we
can't
find a
suitable timezone. So potentially we can default it to the
browsers
timezone that is currently installing OpenMeetings.
This default timzeone will be used whenever there is no
timezone
available for a user or if the timezone of the user is
corrupted.
Sebastian
2013/8/6 Maxim Solodovnik <solomax...@gmail.com>
Additionally Appointment, I guess.
Non-existent XML attribute will be ignored by
simpleframework.
I believe we can let timezones.xml live in our sources and
convert
backups
based on it
On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com <
seba.wag...@gmail.com
wrote:
That might be another approach.
So you are saying we get rid of the Entity OmTimeZone in
total?
Even if we have the timezone in the each of those object,I
think
there
should be a fallback mechanism. Cause with every Java
update
(or I
think
you can even do it manually) you can get updates to the
number/offset
of
the timezones (appearently every year such and such
countries
for
instance
"decide" to switch to have not a Daylight saving time, et
cetera,
or
there
is even a brand new timezone).
So it could happen one day that we have timezone string in
our
application
that is neither known to java.util.Timezone nor to
net.fortuna.ical4j.model.TimeZone. Or a timezone exists in
the
one
and
does
not exist in the other.
I think we should go the extra mile and try to outline the
technical
part
upfront doing anything concretly. It could save us a lot of
time.
Also it
might be good to discuss this publicly as more then one
person
can
then
work on it in parallel.
As far as I can judge you can't save the type
java.util.Timezone
in
a
database.
So it has to be either a string or you store an Integer
(utcTimeZoneOffset). But I really don't like the latter as
it
does
not
handle Daylight savings times.
So the Entities that hold an attribute "omTimeZone" that
would
need
to be
changed:
User
Invitations
MeetingMembers
and they all get a new attribute "String tz"
How would we imagine could the export and import work if
you
import
an
old
backup where the OmTimeZone is set in the user? I guess we
need
a
converter
that can handle OmTimeZone to the new format.
However would that even work currently with
org.simpleframework.xml.Element, when you have an attribute
that
does
just
no more exist ?
Any other considerations that are not yet covered?
Sebastian
2013/8/6 Maxim Solodovnik <solomax...@gmail.com>
I like the idea of having less custom issues
I believe TZ field in all our objects can easily be just
a
string
like:
"Europe/Berlin"
On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik <
solomax...@gmail.com
wrote:
I have: It is impossible to get User timezone (you only
can
get
tz
shift
and/or dst shift and if dst is in effect)
According to iCal4J time zone mapping I guess the name
should
be
the
same
On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com<
seba.wag...@gmail.com> wrote:
Okay,
after a bit of back and forth using the
wicket-jquery-ui
library
I
think
it
might be worth re-evaluating our timezone behaviour.
Basically it seems like the approach to show the UI
in a
timezone
different
from the users browser/os is a non common approach.
And
eventually
we
can
directly migrate away from it.
So the proposal would be:
Show the calendar UI and any timezone relevant
information
in
the
browser's
timezone.
To resolve the issues in the invitations I would
suggest
the
following
changes:
- When the user signs up the timezone is no more
editable/not
even
shown
maybe or read only and taken from the browser/client
os
- Everytime the user logs in the timezone field in
the
users
profile
is
updated with the current timezone of the
browser/client
os.
The idea might be that we add a new entry in the
table
OmTimeZone
whenever
we detect any user with a new timezone.
- Login view the Flash application will no more be
possible.
The
Openlaszlo application will only be used for the
conference
room
itself
By doing that it should basically all just work fine.
But now comes the elefant :) We need a mapping between
iCal4J
timezones
and
java.util.Timezone.
iCal4J is using net.fortuna.ical4j.model.TimeZone and
we
only
have
java.util.TimeZones. This is the historical reason why
the
code
is a
little
bit messed up with various timezone calculations and
fallbacks.
So it will be a major refactoring that should be
planned
and
broken
down
in
several phases.
We will change and touch all and any kind of
functionality
in
OpenMeetings.
It will require quite a bit of regression testing to
check
if
nothing
is
broken.
We generall said refactorings like this are not part
of
OpenMeetings
3.0.
And once we start this there is no way back. It will
delay
any
potential
release by 1 - 2 months.
What is the general opinion about this ?
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
WBR
Maxim aka solomax
--
WBR
Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
WBR
Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
WBR
Maxim aka solomax
--
WBR
Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
WBR
Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
--
WBR
Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
