You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2013/08/06 10:17:56 UTC
Discussing changes of Desing/Architecture of timezone implementation
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.wagner@gmail.com
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by "seba.wagner@gmail.com" <se...@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 <so...@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.wagner@gmail.com <
> seba.wagner@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 <so...@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.wagner@gmail.com <
> > > seba.wagner@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 <so...@gmail.com>
> > > >
> > > > > The correct URL is http://timezonepicker.com/
> > > > >
> > > > >
> > > > > On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <
> > solomax666@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.wagner@gmail.com <
> > > > > > seba.wagner@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 <so...@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.wagner@gmail.com <
> > > > > >> > seba.wagner@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 <so...@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 <
> > > > > >> solomax666@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.wagner@gmail.com <
> > > > > >> > > > > seba.wagner@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.wagner@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.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
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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.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
> >
>
>
>
> --
> 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: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@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.wagner@gmail.com <seba.wagner@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 <so...@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.wagner@gmail.com <
> > seba.wagner@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 <so...@gmail.com>
> > >
> > > > The correct URL is http://timezonepicker.com/
> > > >
> > > >
> > > > On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <
> solomax666@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.wagner@gmail.com <
> > > > > seba.wagner@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 <so...@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.wagner@gmail.com <
> > > > >> > seba.wagner@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 <so...@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 <
> > > > >> solomax666@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.wagner@gmail.com <
> > > > >> > > > > seba.wagner@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.wagner@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.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
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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.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
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by "seba.wagner@gmail.com" <se...@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."
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 <so...@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.wagner@gmail.com <
> seba.wagner@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 <so...@gmail.com>
> >
> > > The correct URL is http://timezonepicker.com/
> > >
> > >
> > > On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <solomax666@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.wagner@gmail.com <
> > > > seba.wagner@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 <so...@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.wagner@gmail.com <
> > > >> > seba.wagner@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 <so...@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 <
> > > >> solomax666@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.wagner@gmail.com <
> > > >> > > > > seba.wagner@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.wagner@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.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
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > 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.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: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@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.wagner@gmail.com <
seba.wagner@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 <so...@gmail.com>
>
> > The correct URL is http://timezonepicker.com/
> >
> >
> > On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <solomax666@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.wagner@gmail.com <
> > > seba.wagner@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 <so...@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.wagner@gmail.com <
> > >> > seba.wagner@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 <so...@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 <
> > >> solomax666@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.wagner@gmail.com <
> > >> > > > > seba.wagner@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.wagner@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.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
> > >>
> > >
> > >
> > >
> > > --
> > > 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.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com>
> The correct URL is http://timezonepicker.com/
>
>
> On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <solomax666@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.wagner@gmail.com <
> > seba.wagner@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 <so...@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.wagner@gmail.com <
> >> > seba.wagner@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 <so...@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 <
> >> solomax666@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.wagner@gmail.com <
> >> > > > > seba.wagner@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.wagner@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.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
> >>
> >
> >
> >
> > --
> > 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.wagner@gmail.com
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@gmail.com>.
The correct URL is http://timezonepicker.com/
On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik <so...@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.wagner@gmail.com <
> seba.wagner@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 <so...@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.wagner@gmail.com <
>> > seba.wagner@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 <so...@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 <
>> solomax666@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.wagner@gmail.com <
>> > > > > seba.wagner@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.wagner@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.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
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@gmail.com>.
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.wagner@gmail.com <seba.wagner@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 <so...@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.wagner@gmail.com <
> > seba.wagner@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 <so...@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 <
> solomax666@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.wagner@gmail.com <
> > > > > seba.wagner@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.wagner@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.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
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@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.wagner@gmail.com <
> seba.wagner@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 <so...@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 <solomax666@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.wagner@gmail.com <
> > > > seba.wagner@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.wagner@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.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: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@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.wagner@gmail.com <seba.wagner@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 <so...@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 <solomax666@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.wagner@gmail.com <
> > > seba.wagner@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.wagner@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.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@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 <solomax666@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.wagner@gmail.com <
> > seba.wagner@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.wagner@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.wagner@gmail.com
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@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 <so...@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.wagner@gmail.com <
> seba.wagner@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.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: Discussing changes of Desing/Architecture of timezone implementation
Posted by Maxim Solodovnik <so...@gmail.com>.
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.wagner@gmail.com <seba.wagner@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.wagner@gmail.com
>
--
WBR
Maxim aka solomax