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/09 09:24:24 UTC

[VOTE] Discussing changes of Desing/Architecture of timezone implementation

So probably we can put this up for a vote?

The only alternative I see as a short term fix is to overwrite the users
"OmTimeZone" with the current timezone of the browser.

Alternative 1:
Short term fix, default OmTimeZone to current timezone in browser,
overwrite everytime the user logs in (Estimated 1-2 weeks of work)

Alternative 2:
Rewrite and refactor to get rid of entire OmTimeZone (as described in
attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt)
 (Estimated 1-2 months of work)

The effort estimates are including time that is needed for fixing bugs and
do the testing.

Vote for 1 if you like to see this implemented as part of OpenMeetings
3.0.0, vote for Alternative 2 if you want to see this implemented as part
of OpenMeetings 3.0.0.

Thanks,
Sebastian


2013/8/8 seba.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
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
An admin should always be able to edit all fields from my point of view.

And also appointments need an owner from my point of view. Cause only the
owner/organiser of a calendar event can edit or delete an event. Other
users can't. They see it in the calendar, the can click on it, see the
details, use the link from the calendar ui to the linked conference room
for that meeting but: They can't add or remove attendee's, edit the time or
any other field and they cannot change the time or duration of the meeting.
This functionality was already present in Openmeetings 2.x

Sebastian
On 17 Aug 2013 03:14, "Maxim Solodovnik" <so...@gmail.com> wrote:

> I just rethink it.
> Admin in our system can see all objects, so all users are editable by
> admin.
> I'm not sure it is good idea to be able to change user type :(
>
>
> On Fri, Aug 16, 2013 at 10:19 AM, Maxim Solodovnik <so...@gmail.com>wrote:
>
>> Hello Sebastian,
>>
>> I believe there is no need to add Appointment owner to the Appointment
>> attendees since:
>> 1) it can't be changed/deleted
>> 2) owner status is nothing but accepted (I guess)
>>
>> So every attendee of the Appointment is:
>> 1) OM User (internal/external/contact)
>> 2) has MeetingMember record connecting User with Appointment and storing
>> attendee status
>>
>> not sure how is it currently (need to double-check)
>>
>> According to your assumptions:
>> 1) I'm not sure it is good idea if Admin will be able to edit contact of
>> the user
>>  2) Current code should be modified to:
>>    a) check different users can have contacts with same email address and
>> with other fields differs (same check should be performed for the external
>> users) -- I believe this can be done by Unit tests
>>    b) check contact of different users are not accessible by others
>> 3) The field of type enum is savable as String in all databases.
>>
>> I'll try to add these tests/logic in nearest week(s)
>> Hopefully will have time for that
>>
>>
>> On Fri, Aug 16, 2013 at 6:53 AM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> And for the rest of the changes (modification of MeetingMember), I am
>>> fine with that,
>>> under the assumption:
>>>  - All this data is stored now in the user entity
>>>  - The field "type" in the user entity becomes editable in the user
>>> administration just like any other field
>>>  - User of type contacts are saveble in the user administration
>>>  - The field type "enum" is supported by OpenJPA and all major database
>>> vendors
>>>
>>> Cheers,
>>> Sebastian
>>>
>>>
>>>
>>> 2013/8/16 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> If you are only an attendee of a meeting and an internal OpenMeetings
>>>> user, will you link it to the same event or have two events for every user?
>>>> How is it currently?
>>>>
>>>> Sebastian
>>>> On 15 Aug 2013 15:24, "Maxim Solodovnik" <so...@gmail.com> wrote:
>>>>
>>>>> Hello Sebastian,
>>>>>
>>>>> I would like to discuss the modification of MeetingMember entity.
>>>>> IMHO this entity should contain only the following fields:
>>>>>
>>>>> private long id;
>>>>> private User user;
>>>>> private Appointment appointment;
>>>>> //!!! MAYBE it should be enum
>>>>> private String status; //status of the appointment denial, acceptance,
>>>>> wait.
>>>>> private Date updatetime;
>>>>> private Invitations invitation; //not null in case Invitation was sent
>>>>> to the external attendee
>>>>> private boolean isConnectedEvent; //for the contact requests
>>>>>
>>>>> all other fields should be removed.
>>>>>
>>>>> I also would vote for renaming Appointment.userId field to
>>>>> Appointment.owner
>>>>>
>>>>> And I would change Long and Boolean fields to long and boolean where
>>>>> possible
>>>>>
>>>>> What do you think about it?
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <
>>>>> solomax666@gmail.com> wrote:
>>>>>
>>>>>> Thanks for the updates.
>>>>>> I'll try to investigate all use cases and try to create proposal of
>>>>>> how to make user tz consistent, if it is impossible it make sense to make
>>>>>> this setting unchangeable by the user.
>>>>>>
>>>>>>
>>>>>> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
>>>>>> seba.wagner@gmail.com> wrote:
>>>>>>
>>>>>>> I have basically done the first task and replaced the OmTimeZone
>>>>>>> from the Invitations entity.
>>>>>>> I tried to keep any kind of functionality for matching the TimeZone
>>>>>>> in the TimezoneUtil.
>>>>>>> The String that I stored in the Invitations Entity is basically the
>>>>>>> result of java.util.TimeZone.getId().
>>>>>>>
>>>>>>> http://svn.apache.org/r1512557
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>
>>>>>>> New Branch:
>>>>>>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>>>>>>> based on trunk r1512224
>>>>>>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>>>>>>  <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>>>>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>>>>>>
>>>>>>>>> is a summary jira, actual work is broken down in sub issues.
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>>
>>>>>>>>> Maxim,
>>>>>>>>>>
>>>>>>>>>> just one thing: The "new" implemention will of course also
>>>>>>>>>> "silently" overwrite the timezone string with every login.
>>>>>>>>>> Otherwise we would send invitations to that user in a potentially
>>>>>>>>>> wrong configured timezone.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>>>>>>> We can create a feature branch based on trunk and do the work
>>>>>>>>>>> inside that.
>>>>>>>>>>>
>>>>>>>>>>> Sebastian
>>>>>>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> My vote is for Alternative 2.
>>>>>>>>>>>>
>>>>>>>>>>>> Vasiliy
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only alternative I see as a short term fix is to overwrite
>>>>>>>>>>>>> the users
>>>>>>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alternative 1:
>>>>>>>>>>>>> Short term fix, default OmTimeZone to current timezone in
>>>>>>>>>>>>> browser,
>>>>>>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of
>>>>>>>>>>>>> work)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alternative 2:
>>>>>>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as
>>>>>>>>>>>>> described in
>>>>>>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>>>>>>> rem2snf74srvftnt<http://markmail.org/message/rem2snf74srvftnt>
>>>>>>>>>>>>> )
>>>>>>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The effort estimates are including time that is needed for
>>>>>>>>>>>>> fixing bugs and
>>>>>>>>>>>>> do the testing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>>>>>>> OpenMeetings
>>>>>>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this
>>>>>>>>>>>>> implemented as part
>>>>>>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
I just rethink it.
Admin in our system can see all objects, so all users are editable by admin.
I'm not sure it is good idea to be able to change user type :(


On Fri, Aug 16, 2013 at 10:19 AM, Maxim Solodovnik <so...@gmail.com>wrote:

> Hello Sebastian,
>
> I believe there is no need to add Appointment owner to the Appointment
> attendees since:
> 1) it can't be changed/deleted
> 2) owner status is nothing but accepted (I guess)
>
> So every attendee of the Appointment is:
> 1) OM User (internal/external/contact)
> 2) has MeetingMember record connecting User with Appointment and storing
> attendee status
>
> not sure how is it currently (need to double-check)
>
> According to your assumptions:
> 1) I'm not sure it is good idea if Admin will be able to edit contact of
> the user
> 2) Current code should be modified to:
>    a) check different users can have contacts with same email address and
> with other fields differs (same check should be performed for the external
> users) -- I believe this can be done by Unit tests
>    b) check contact of different users are not accessible by others
> 3) The field of type enum is savable as String in all databases.
>
> I'll try to add these tests/logic in nearest week(s)
> Hopefully will have time for that
>
>
> On Fri, Aug 16, 2013 at 6:53 AM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> And for the rest of the changes (modification of MeetingMember), I am
>> fine with that,
>> under the assumption:
>>  - All this data is stored now in the user entity
>>  - The field "type" in the user entity becomes editable in the user
>> administration just like any other field
>>  - User of type contacts are saveble in the user administration
>>  - The field type "enum" is supported by OpenJPA and all major database
>> vendors
>>
>> Cheers,
>> Sebastian
>>
>>
>>
>> 2013/8/16 seba.wagner@gmail.com <se...@gmail.com>
>>
>> If you are only an attendee of a meeting and an internal OpenMeetings
>>> user, will you link it to the same event or have two events for every user?
>>> How is it currently?
>>>
>>> Sebastian
>>> On 15 Aug 2013 15:24, "Maxim Solodovnik" <so...@gmail.com> wrote:
>>>
>>>> Hello Sebastian,
>>>>
>>>> I would like to discuss the modification of MeetingMember entity.
>>>> IMHO this entity should contain only the following fields:
>>>>
>>>> private long id;
>>>> private User user;
>>>> private Appointment appointment;
>>>> //!!! MAYBE it should be enum
>>>> private String status; //status of the appointment denial, acceptance,
>>>> wait.
>>>> private Date updatetime;
>>>> private Invitations invitation; //not null in case Invitation was sent
>>>> to the external attendee
>>>> private boolean isConnectedEvent; //for the contact requests
>>>>
>>>> all other fields should be removed.
>>>>
>>>> I also would vote for renaming Appointment.userId field to
>>>> Appointment.owner
>>>>
>>>> And I would change Long and Boolean fields to long and boolean where
>>>> possible
>>>>
>>>> What do you think about it?
>>>>
>>>>
>>>>
>>>> On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <solomax666@gmail.com
>>>> > wrote:
>>>>
>>>>> Thanks for the updates.
>>>>> I'll try to investigate all use cases and try to create proposal of
>>>>> how to make user tz consistent, if it is impossible it make sense to make
>>>>> this setting unchangeable by the user.
>>>>>
>>>>>
>>>>> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
>>>>> seba.wagner@gmail.com> wrote:
>>>>>
>>>>>> I have basically done the first task and replaced the OmTimeZone from
>>>>>> the Invitations entity.
>>>>>> I tried to keep any kind of functionality for matching the TimeZone
>>>>>> in the TimezoneUtil.
>>>>>> The String that I stored in the Invitations Entity is basically the
>>>>>> result of java.util.TimeZone.getId().
>>>>>>
>>>>>> http://svn.apache.org/r1512557
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>
>>>>>> New Branch:
>>>>>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>>>>>> based on trunk r1512224
>>>>>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>>>>>  <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>>>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>>>>>
>>>>>>>> is a summary jira, actual work is broken down in sub issues.
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>
>>>>>>>> Maxim,
>>>>>>>>>
>>>>>>>>> just one thing: The "new" implemention will of course also
>>>>>>>>> "silently" overwrite the timezone string with every login.
>>>>>>>>> Otherwise we would send invitations to that user in a potentially
>>>>>>>>> wrong configured timezone.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>>
>>>>>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>>>>>> We can create a feature branch based on trunk and do the work
>>>>>>>>>> inside that.
>>>>>>>>>>
>>>>>>>>>> Sebastian
>>>>>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> My vote is for Alternative 2.
>>>>>>>>>>>
>>>>>>>>>>> Vasiliy
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>>>>>
>>>>>>>>>>>> The only alternative I see as a short term fix is to overwrite
>>>>>>>>>>>> the users
>>>>>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>>>>>
>>>>>>>>>>>> Alternative 1:
>>>>>>>>>>>> Short term fix, default OmTimeZone to current timezone in
>>>>>>>>>>>> browser,
>>>>>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of
>>>>>>>>>>>> work)
>>>>>>>>>>>>
>>>>>>>>>>>> Alternative 2:
>>>>>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as
>>>>>>>>>>>> described in
>>>>>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>
>>>>>>>>>>>> )
>>>>>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>>>>>
>>>>>>>>>>>> The effort estimates are including time that is needed for
>>>>>>>>>>>> fixing bugs and
>>>>>>>>>>>> do the testing.
>>>>>>>>>>>>
>>>>>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>>>>>> OpenMeetings
>>>>>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this
>>>>>>>>>>>> implemented as part
>>>>>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sebastian,

I believe there is no need to add Appointment owner to the Appointment
attendees since:
1) it can't be changed/deleted
2) owner status is nothing but accepted (I guess)

So every attendee of the Appointment is:
1) OM User (internal/external/contact)
2) has MeetingMember record connecting User with Appointment and storing
attendee status

not sure how is it currently (need to double-check)

According to your assumptions:
1) I'm not sure it is good idea if Admin will be able to edit contact of
the user
2) Current code should be modified to:
   a) check different users can have contacts with same email address and
with other fields differs (same check should be performed for the external
users) -- I believe this can be done by Unit tests
   b) check contact of different users are not accessible by others
3) The field of type enum is savable as String in all databases.

I'll try to add these tests/logic in nearest week(s)
Hopefully will have time for that


On Fri, Aug 16, 2013 at 6:53 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:

> And for the rest of the changes (modification of MeetingMember), I am fine
> with that,
> under the assumption:
>  - All this data is stored now in the user entity
>  - The field "type" in the user entity becomes editable in the user
> administration just like any other field
>  - User of type contacts are saveble in the user administration
>  - The field type "enum" is supported by OpenJPA and all major database
> vendors
>
> Cheers,
> Sebastian
>
>
>
> 2013/8/16 seba.wagner@gmail.com <se...@gmail.com>
>
> If you are only an attendee of a meeting and an internal OpenMeetings
>> user, will you link it to the same event or have two events for every user?
>> How is it currently?
>>
>> Sebastian
>> On 15 Aug 2013 15:24, "Maxim Solodovnik" <so...@gmail.com> wrote:
>>
>>> Hello Sebastian,
>>>
>>> I would like to discuss the modification of MeetingMember entity.
>>> IMHO this entity should contain only the following fields:
>>>
>>> private long id;
>>> private User user;
>>> private Appointment appointment;
>>> //!!! MAYBE it should be enum
>>> private String status; //status of the appointment denial, acceptance,
>>> wait.
>>> private Date updatetime;
>>> private Invitations invitation; //not null in case Invitation was sent
>>> to the external attendee
>>> private boolean isConnectedEvent; //for the contact requests
>>>
>>> all other fields should be removed.
>>>
>>> I also would vote for renaming Appointment.userId field to
>>> Appointment.owner
>>>
>>> And I would change Long and Boolean fields to long and boolean where
>>> possible
>>>
>>> What do you think about it?
>>>
>>>
>>>
>>> On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>>>
>>>> Thanks for the updates.
>>>> I'll try to investigate all use cases and try to create proposal of how
>>>> to make user tz consistent, if it is impossible it make sense to make this
>>>> setting unchangeable by the user.
>>>>
>>>>
>>>> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
>>>> seba.wagner@gmail.com> wrote:
>>>>
>>>>> I have basically done the first task and replaced the OmTimeZone from
>>>>> the Invitations entity.
>>>>> I tried to keep any kind of functionality for matching the TimeZone in
>>>>> the TimezoneUtil.
>>>>> The String that I stored in the Invitations Entity is basically the
>>>>> result of java.util.TimeZone.getId().
>>>>>
>>>>> http://svn.apache.org/r1512557
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>
>>>>> New Branch:
>>>>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>>>>> based on trunk r1512224
>>>>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>>>>  <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>>>>
>>>>>>> is a summary jira, actual work is broken down in sub issues.
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>
>>>>>>> Maxim,
>>>>>>>>
>>>>>>>> just one thing: The "new" implemention will of course also
>>>>>>>> "silently" overwrite the timezone string with every login.
>>>>>>>> Otherwise we would send invitations to that user in a potentially
>>>>>>>> wrong configured timezone.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>>
>>>>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>>>>> We can create a feature branch based on trunk and do the work
>>>>>>>>> inside that.
>>>>>>>>>
>>>>>>>>> Sebastian
>>>>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> My vote is for Alternative 2.
>>>>>>>>>>
>>>>>>>>>> Vasiliy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>>>>
>>>>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>>>>
>>>>>>>>>>> The only alternative I see as a short term fix is to overwrite
>>>>>>>>>>> the users
>>>>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>>>>
>>>>>>>>>>> Alternative 1:
>>>>>>>>>>> Short term fix, default OmTimeZone to current timezone in
>>>>>>>>>>> browser,
>>>>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of
>>>>>>>>>>> work)
>>>>>>>>>>>
>>>>>>>>>>> Alternative 2:
>>>>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as
>>>>>>>>>>> described in
>>>>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>>>>
>>>>>>>>>>> The effort estimates are including time that is needed for
>>>>>>>>>>> fixing bugs and
>>>>>>>>>>> do the testing.
>>>>>>>>>>>
>>>>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>>>>> OpenMeetings
>>>>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this
>>>>>>>>>>> implemented as part
>>>>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Sebastian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
And for the rest of the changes (modification of MeetingMember), I am fine
with that,
under the assumption:
 - All this data is stored now in the user entity
 - The field "type" in the user entity becomes editable in the user
administration just like any other field
 - User of type contacts are saveble in the user administration
 - The field type "enum" is supported by OpenJPA and all major database
vendors

Cheers,
Sebastian



2013/8/16 seba.wagner@gmail.com <se...@gmail.com>

> If you are only an attendee of a meeting and an internal OpenMeetings
> user, will you link it to the same event or have two events for every user?
> How is it currently?
>
> Sebastian
> On 15 Aug 2013 15:24, "Maxim Solodovnik" <so...@gmail.com> wrote:
>
>> Hello Sebastian,
>>
>> I would like to discuss the modification of MeetingMember entity.
>> IMHO this entity should contain only the following fields:
>>
>> private long id;
>> private User user;
>> private Appointment appointment;
>> //!!! MAYBE it should be enum
>> private String status; //status of the appointment denial, acceptance,
>> wait.
>> private Date updatetime;
>> private Invitations invitation; //not null in case Invitation was sent to
>> the external attendee
>> private boolean isConnectedEvent; //for the contact requests
>>
>> all other fields should be removed.
>>
>> I also would vote for renaming Appointment.userId field to
>> Appointment.owner
>>
>> And I would change Long and Boolean fields to long and boolean where
>> possible
>>
>> What do you think about it?
>>
>>
>>
>> On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>>
>>> Thanks for the updates.
>>> I'll try to investigate all use cases and try to create proposal of how
>>> to make user tz consistent, if it is impossible it make sense to make this
>>> setting unchangeable by the user.
>>>
>>>
>>> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> wrote:
>>>
>>>> I have basically done the first task and replaced the OmTimeZone from
>>>> the Invitations entity.
>>>> I tried to keep any kind of functionality for matching the TimeZone in
>>>> the TimezoneUtil.
>>>> The String that I stored in the Invitations Entity is basically the
>>>> result of java.util.TimeZone.getId().
>>>>
>>>> http://svn.apache.org/r1512557
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>
>>>> New Branch:
>>>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>>>> based on trunk r1512224
>>>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>>>  <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>
>>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>>>
>>>>>> is a summary jira, actual work is broken down in sub issues.
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>
>>>>>> Maxim,
>>>>>>>
>>>>>>> just one thing: The "new" implemention will of course also
>>>>>>> "silently" overwrite the timezone string with every login.
>>>>>>> Otherwise we would send invitations to that user in a potentially
>>>>>>> wrong configured timezone.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>
>>>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>>>> We can create a feature branch based on trunk and do the work
>>>>>>>> inside that.
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My vote is for Alternative 2.
>>>>>>>>>
>>>>>>>>> Vasiliy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>>>
>>>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>>>
>>>>>>>>>> The only alternative I see as a short term fix is to overwrite
>>>>>>>>>> the users
>>>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>>>
>>>>>>>>>> Alternative 1:
>>>>>>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>>>>>>
>>>>>>>>>> Alternative 2:
>>>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as
>>>>>>>>>> described in
>>>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>>>
>>>>>>>>>> The effort estimates are including time that is needed for fixing
>>>>>>>>>> bugs and
>>>>>>>>>> do the testing.
>>>>>>>>>>
>>>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>>>> OpenMeetings
>>>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented
>>>>>>>>>> as part
>>>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sebastian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
If you are only an attendee of a meeting and an internal OpenMeetings user,
will you link it to the same event or have two events for every user?
How is it currently?

Sebastian
On 15 Aug 2013 15:24, "Maxim Solodovnik" <so...@gmail.com> wrote:

> Hello Sebastian,
>
> I would like to discuss the modification of MeetingMember entity.
> IMHO this entity should contain only the following fields:
>
> private long id;
> private User user;
> private Appointment appointment;
> //!!! MAYBE it should be enum
> private String status; //status of the appointment denial, acceptance,
> wait.
> private Date updatetime;
> private Invitations invitation; //not null in case Invitation was sent to
> the external attendee
> private boolean isConnectedEvent; //for the contact requests
>
> all other fields should be removed.
>
> I also would vote for renaming Appointment.userId field to
> Appointment.owner
>
> And I would change Long and Boolean fields to long and boolean where
> possible
>
> What do you think about it?
>
>
>
> On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>
>> Thanks for the updates.
>> I'll try to investigate all use cases and try to create proposal of how
>> to make user tz consistent, if it is impossible it make sense to make this
>> setting unchangeable by the user.
>>
>>
>> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> I have basically done the first task and replaced the OmTimeZone from
>>> the Invitations entity.
>>> I tried to keep any kind of functionality for matching the TimeZone in
>>> the TimezoneUtil.
>>> The String that I stored in the Invitations Entity is basically the
>>> result of java.util.TimeZone.getId().
>>>
>>> http://svn.apache.org/r1512557
>>>
>>> Sebastian
>>>
>>>
>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> New Branch:
>>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>>> based on trunk r1512224
>>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>>   <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>
>>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>>
>>>>> is a summary jira, actual work is broken down in sub issues.
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>
>>>>> Maxim,
>>>>>>
>>>>>> just one thing: The "new" implemention will of course also "silently"
>>>>>> overwrite the timezone string with every login.
>>>>>> Otherwise we would send invitations to that user in a potentially
>>>>>> wrong configured timezone.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>
>>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>>> We can create a feature branch based on trunk and do the work inside
>>>>>>> that.
>>>>>>>
>>>>>>> Sebastian
>>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My vote is for Alternative 2.
>>>>>>>>
>>>>>>>> Vasiliy
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>>
>>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>>
>>>>>>>>> The only alternative I see as a short term fix is to overwrite the
>>>>>>>>> users
>>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>>
>>>>>>>>> Alternative 1:
>>>>>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>>>>>
>>>>>>>>> Alternative 2:
>>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described
>>>>>>>>> in
>>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>>
>>>>>>>>> The effort estimates are including time that is needed for fixing
>>>>>>>>> bugs and
>>>>>>>>> do the testing.
>>>>>>>>>
>>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>>> OpenMeetings
>>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented
>>>>>>>>> as part
>>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sebastian,

I would like to discuss the modification of MeetingMember entity.
IMHO this entity should contain only the following fields:

private long id;
private User user;
private Appointment appointment;
//!!! MAYBE it should be enum
private String status; //status of the appointment denial, acceptance, wait.
private Date updatetime;
private Invitations invitation; //not null in case Invitation was sent to
the external attendee
private boolean isConnectedEvent; //for the contact requests

all other fields should be removed.

I also would vote for renaming Appointment.userId field to Appointment.owner

And I would change Long and Boolean fields to long and boolean where
possible

What do you think about it?



On Sat, Aug 10, 2013 at 1:11 PM, Maxim Solodovnik <so...@gmail.com>wrote:

> Thanks for the updates.
> I'll try to investigate all use cases and try to create proposal of how to
> make user tz consistent, if it is impossible it make sense to make this
> setting unchangeable by the user.
>
>
> On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> I have basically done the first task and replaced the OmTimeZone from the
>> Invitations entity.
>> I tried to keep any kind of functionality for matching the TimeZone in
>> the TimezoneUtil.
>> The String that I stored in the Invitations Entity is basically the
>> result of java.util.TimeZone.getId().
>>
>> http://svn.apache.org/r1512557
>>
>> Sebastian
>>
>>
>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>
>> New Branch:
>>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>>> based on trunk r1512224
>>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>>   <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>>
>>> Sebastian
>>>
>>>
>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>>
>>>> is a summary jira, actual work is broken down in sub issues.
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>
>>>> Maxim,
>>>>>
>>>>> just one thing: The "new" implemention will of course also "silently"
>>>>> overwrite the timezone string with every login.
>>>>> Otherwise we would send invitations to that user in a potentially
>>>>> wrong configured timezone.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>>
>>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>>> We can create a feature branch based on trunk and do the work inside
>>>>>> that.
>>>>>>
>>>>>> Sebastian
>>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>>>>>>
>>>>>>> My vote is for Alternative 2.
>>>>>>>
>>>>>>> Vasiliy
>>>>>>>
>>>>>>>
>>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>>
>>>>>>>> So probably we can put this up for a vote?
>>>>>>>>
>>>>>>>> The only alternative I see as a short term fix is to overwrite the
>>>>>>>> users
>>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>>
>>>>>>>> Alternative 1:
>>>>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>>>>
>>>>>>>> Alternative 2:
>>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described
>>>>>>>> in
>>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>>
>>>>>>>> The effort estimates are including time that is needed for fixing
>>>>>>>> bugs and
>>>>>>>> do the testing.
>>>>>>>>
>>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>>> OpenMeetings
>>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented
>>>>>>>> as part
>>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WBR
>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
Thanks for the updates.
I'll try to investigate all use cases and try to create proposal of how to
make user tz consistent, if it is impossible it make sense to make this
setting unchangeable by the user.


On Sat, Aug 10, 2013 at 10:41 AM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:

> I have basically done the first task and replaced the OmTimeZone from the
> Invitations entity.
> I tried to keep any kind of functionality for matching the TimeZone in the
> TimezoneUtil.
> The String that I stored in the Invitations Entity is basically the result
> of java.util.TimeZone.getId().
>
> http://svn.apache.org/r1512557
>
> Sebastian
>
>
> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>
> New Branch:
>> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
>> based on trunk r1512224
>>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>>   <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>>
>> Sebastian
>>
>>
>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>
>> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>>
>>> is a summary jira, actual work is broken down in sub issues.
>>>
>>> Sebastian
>>>
>>>
>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> Maxim,
>>>>
>>>> just one thing: The "new" implemention will of course also "silently"
>>>> overwrite the timezone string with every login.
>>>> Otherwise we would send invitations to that user in a potentially wrong
>>>> configured timezone.
>>>>
>>>>
>>>>
>>>>
>>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>>
>>>> My vote is also 2. I will create a couple of jiras later today.
>>>>> We can create a feature branch based on trunk and do the work inside
>>>>> that.
>>>>>
>>>>> Sebastian
>>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>>>>>
>>>>>> My vote is for Alternative 2.
>>>>>>
>>>>>> Vasiliy
>>>>>>
>>>>>>
>>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>>
>>>>>>> So probably we can put this up for a vote?
>>>>>>>
>>>>>>> The only alternative I see as a short term fix is to overwrite the
>>>>>>> users
>>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>>
>>>>>>> Alternative 1:
>>>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>>>
>>>>>>> Alternative 2:
>>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>>   (Estimated 1-2 months of work)
>>>>>>>
>>>>>>> The effort estimates are including time that is needed for fixing
>>>>>>> bugs and
>>>>>>> do the testing.
>>>>>>>
>>>>>>> Vote for 1 if you like to see this implemented as part of
>>>>>>> OpenMeetings
>>>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as
>>>>>>> part
>>>>>>> of OpenMeetings 3.0.0.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WBR
>>>>>>>>> Maxim aka solomax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
I have basically done the first task and replaced the OmTimeZone from the
Invitations entity.
I tried to keep any kind of functionality for matching the TimeZone in the
TimezoneUtil.
The String that I stored in the Invitations Entity is basically the result
of java.util.TimeZone.getId().

http://svn.apache.org/r1512557

Sebastian


2013/8/10 seba.wagner@gmail.com <se...@gmail.com>

> New Branch:
> http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
> based on trunk r1512224
>  <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
>   <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
>  Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
>
> Sebastian
>
>
> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>
> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>>
>> is a summary jira, actual work is broken down in sub issues.
>>
>> Sebastian
>>
>>
>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>
>> Maxim,
>>>
>>> just one thing: The "new" implemention will of course also "silently"
>>> overwrite the timezone string with every login.
>>> Otherwise we would send invitations to that user in a potentially wrong
>>> configured timezone.
>>>
>>>
>>>
>>>
>>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> My vote is also 2. I will create a couple of jiras later today.
>>>> We can create a feature branch based on trunk and do the work inside
>>>> that.
>>>>
>>>> Sebastian
>>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>>>>
>>>>> My vote is for Alternative 2.
>>>>>
>>>>> Vasiliy
>>>>>
>>>>>
>>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>>
>>>>>> So probably we can put this up for a vote?
>>>>>>
>>>>>> The only alternative I see as a short term fix is to overwrite the
>>>>>> users
>>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>>
>>>>>> Alternative 1:
>>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>>
>>>>>> Alternative 2:
>>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>>   (Estimated 1-2 months of work)
>>>>>>
>>>>>> The effort estimates are including time that is needed for fixing
>>>>>> bugs and
>>>>>> do the testing.
>>>>>>
>>>>>> Vote for 1 if you like to see this implemented as part of OpenMeetings
>>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as
>>>>>> part
>>>>>> of OpenMeetings 3.0.0.
>>>>>>
>>>>>> Thanks,
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WBR
>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
New Branch:
http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/
based on trunk r1512224
 <https://issues.apache.org/jira/browse/OPENMEETINGS-752#>
  <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner>
 Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/

Sebastian


2013/8/10 seba.wagner@gmail.com <se...@gmail.com>

> https://issues.apache.org/jira/browse/OPENMEETINGS-745
>
> is a summary jira, actual work is broken down in sub issues.
>
> Sebastian
>
>
> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>
> Maxim,
>>
>> just one thing: The "new" implemention will of course also "silently"
>> overwrite the timezone string with every login.
>> Otherwise we would send invitations to that user in a potentially wrong
>> configured timezone.
>>
>>
>>
>>
>> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>>
>> My vote is also 2. I will create a couple of jiras later today.
>>> We can create a feature branch based on trunk and do the work inside
>>> that.
>>>
>>> Sebastian
>>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>>>
>>>> My vote is for Alternative 2.
>>>>
>>>> Vasiliy
>>>>
>>>>
>>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>>
>>>>> So probably we can put this up for a vote?
>>>>>
>>>>> The only alternative I see as a short term fix is to overwrite the
>>>>> users
>>>>> "OmTimeZone" with the current timezone of the browser.
>>>>>
>>>>> Alternative 1:
>>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>>
>>>>> Alternative 2:
>>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>>>>> attached discussion or thread: http://markmail.org/message/**
>>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>>   (Estimated 1-2 months of work)
>>>>>
>>>>> The effort estimates are including time that is needed for fixing bugs
>>>>> and
>>>>> do the testing.
>>>>>
>>>>> Vote for 1 if you like to see this implemented as part of OpenMeetings
>>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as
>>>>> part
>>>>> of OpenMeetings 3.0.0.
>>>>>
>>>>> Thanks,
>>>>> Sebastian
>>>>>
>>>>>
>>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WBR
>>>>>>>>> Maxim aka solomax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
https://issues.apache.org/jira/browse/OPENMEETINGS-745

is a summary jira, actual work is broken down in sub issues.

Sebastian


2013/8/10 seba.wagner@gmail.com <se...@gmail.com>

> Maxim,
>
> just one thing: The "new" implemention will of course also "silently"
> overwrite the timezone string with every login.
> Otherwise we would send invitations to that user in a potentially wrong
> configured timezone.
>
>
>
>
> 2013/8/10 seba.wagner@gmail.com <se...@gmail.com>
>
> My vote is also 2. I will create a couple of jiras later today.
>> We can create a feature branch based on trunk and do the work inside that.
>>
>> Sebastian
>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>>
>>> My vote is for Alternative 2.
>>>
>>> Vasiliy
>>>
>>>
>>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>>
>>>> So probably we can put this up for a vote?
>>>>
>>>> The only alternative I see as a short term fix is to overwrite the users
>>>> "OmTimeZone" with the current timezone of the browser.
>>>>
>>>> Alternative 1:
>>>> Short term fix, default OmTimeZone to current timezone in browser,
>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>>
>>>> Alternative 2:
>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>>>> attached discussion or thread: http://markmail.org/message/**
>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>>   (Estimated 1-2 months of work)
>>>>
>>>> The effort estimates are including time that is needed for fixing bugs
>>>> and
>>>> do the testing.
>>>>
>>>> Vote for 1 if you like to see this implemented as part of OpenMeetings
>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as
>>>> part
>>>> of OpenMeetings 3.0.0.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>>>
>>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WBR
>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sebastian Wagner
>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>> http://www.webbase-design.de
>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>> seba.wagner@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Maxim,

just one thing: The "new" implemention will of course also "silently"
overwrite the timezone string with every login.
Otherwise we would send invitations to that user in a potentially wrong
configured timezone.




2013/8/10 seba.wagner@gmail.com <se...@gmail.com>

> My vote is also 2. I will create a couple of jiras later today.
> We can create a feature branch based on trunk and do the work inside that.
>
> Sebastian
> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:
>
>> My vote is for Alternative 2.
>>
>> Vasiliy
>>
>>
>> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>>
>>> So probably we can put this up for a vote?
>>>
>>> The only alternative I see as a short term fix is to overwrite the users
>>> "OmTimeZone" with the current timezone of the browser.
>>>
>>> Alternative 1:
>>> Short term fix, default OmTimeZone to current timezone in browser,
>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>>
>>> Alternative 2:
>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>>> attached discussion or thread: http://markmail.org/message/**
>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>>   (Estimated 1-2 months of work)
>>>
>>> The effort estimates are including time that is needed for fixing bugs
>>> and
>>> do the testing.
>>>
>>> Vote for 1 if you like to see this implemented as part of OpenMeetings
>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as part
>>> of OpenMeetings 3.0.0.
>>>
>>> Thanks,
>>> Sebastian
>>>
>>>
>>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WBR
>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WBR
>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WBR
>>>>>>>>> Maxim aka solomax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>> seba.wagner@gmail.com
>>>>
>>>>
>>>
>>>
>>


-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
My vote is also 2. I will create a couple of jiras later today.
We can create a feature branch based on trunk and do the work inside that.

Sebastian
On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote:

> My vote is for Alternative 2.
>
> Vasiliy
>
>
> On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
>
>> So probably we can put this up for a vote?
>>
>> The only alternative I see as a short term fix is to overwrite the users
>> "OmTimeZone" with the current timezone of the browser.
>>
>> Alternative 1:
>> Short term fix, default OmTimeZone to current timezone in browser,
>> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>>
>> Alternative 2:
>> Rewrite and refactor to get rid of entire OmTimeZone (as described in
>> attached discussion or thread: http://markmail.org/message/**
>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>)
>>   (Estimated 1-2 months of work)
>>
>> The effort estimates are including time that is needed for fixing bugs and
>> do the testing.
>>
>> Vote for 1 if you like to see this implemented as part of OpenMeetings
>> 3.0.0, vote for Alternative 2 if you want to see this implemented as part
>> of OpenMeetings 3.0.0.
>>
>> Thanks,
>> Sebastian
>>
>>
>> 2013/8/8 seba.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<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<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<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sebastian Wagner
>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Maxim aka solomax
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sebastian Wagner
>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>>>>> http://www.webbase-design.de
>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com>
>>>>>>>>>> seba.wagner@gmail.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WBR
>>>>>>>>> Maxim aka solomax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock>
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>>>> seba.wagner@gmail.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock>
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com>
>>> seba.wagner@gmail.com
>>>
>>>
>>
>>
>

Re: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Vasiliy Degtyarev <va...@unipro.ru>.
My vote is for Alternative 2.

Vasiliy


On 09.08.2013 14:24, seba.wagner@gmail.com wrote:
> So probably we can put this up for a vote?
>
> The only alternative I see as a short term fix is to overwrite the users
> "OmTimeZone" with the current timezone of the browser.
>
> Alternative 1:
> Short term fix, default OmTimeZone to current timezone in browser,
> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>
> Alternative 2:
> Rewrite and refactor to get rid of entire OmTimeZone (as described in
> attached discussion or thread: http://markmail.org/message/rem2snf74srvftnt)
>   (Estimated 1-2 months of work)
>
> The effort estimates are including time that is needed for fixing bugs and
> do the testing.
>
> Vote for 1 if you like to see this implemented as part of OpenMeetings
> 3.0.0, vote for Alternative 2 if you want to see this implemented as part
> of OpenMeetings 3.0.0.
>
> Thanks,
> Sebastian
>
>
> 2013/8/8 seba.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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
OK let's wait for the VOTE results then start the refactoring :)


On Fri, Aug 9, 2013 at 3:31 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> Basically the calendar is not timezone safe as it is now. There is no
> option 3 to just leave it as is from my point of view. So something has to
> happen.
>
> Sebastian
> On 9 Aug 2013 20:19, "Maxim Solodovnik" <so...@gmail.com> wrote:
>
> > I don't really like the idea of having setting in the options which is
> > overwritten on every login (silently)
> >
> > My vote is for Alternative 2.
> >
> > @Sebastian
> > I guess Alternative 2 is for 3.1.0? I can try to perform refactoring
> > faster. Then you can handle "fine tuning" of this issue and I can handle
> > Import/Export (might be tricky)
> >
> >
> > On Fri, Aug 9, 2013 at 2:24 PM, seba.wagner@gmail.com <
> > seba.wagner@gmail.com
> > > wrote:
> >
> > > So probably we can put this up for a vote?
> > >
> > > The only alternative I see as a short term fix is to overwrite the
> users
> > > "OmTimeZone" with the current timezone of the browser.
> > >
> > > Alternative 1:
> > > Short term fix, default OmTimeZone to current timezone in browser,
> > > overwrite everytime the user logs in (Estimated 1-2 weeks of work)
> > >
> > > Alternative 2:
> > > Rewrite and refactor to get rid of entire OmTimeZone (as described in
> > > attached discussion or thread:
> > > http://markmail.org/message/rem2snf74srvftnt)
> > >  (Estimated 1-2 months of work)
> > >
> > > The effort estimates are including time that is needed for fixing bugs
> > and
> > > do the testing.
> > >
> > > Vote for 1 if you like to see this implemented as part of OpenMeetings
> > > 3.0.0, vote for Alternative 2 if you want to see this implemented as
> part
> > > of OpenMeetings 3.0.0.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > >
> > > 2013/8/8 seba.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
> > > >
> > >
> > >
> > >
> > > --
> > > 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Basically the calendar is not timezone safe as it is now. There is no
option 3 to just leave it as is from my point of view. So something has to
happen.

Sebastian
On 9 Aug 2013 20:19, "Maxim Solodovnik" <so...@gmail.com> wrote:

> I don't really like the idea of having setting in the options which is
> overwritten on every login (silently)
>
> My vote is for Alternative 2.
>
> @Sebastian
> I guess Alternative 2 is for 3.1.0? I can try to perform refactoring
> faster. Then you can handle "fine tuning" of this issue and I can handle
> Import/Export (might be tricky)
>
>
> On Fri, Aug 9, 2013 at 2:24 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com
> > wrote:
>
> > So probably we can put this up for a vote?
> >
> > The only alternative I see as a short term fix is to overwrite the users
> > "OmTimeZone" with the current timezone of the browser.
> >
> > Alternative 1:
> > Short term fix, default OmTimeZone to current timezone in browser,
> > overwrite everytime the user logs in (Estimated 1-2 weeks of work)
> >
> > Alternative 2:
> > Rewrite and refactor to get rid of entire OmTimeZone (as described in
> > attached discussion or thread:
> > http://markmail.org/message/rem2snf74srvftnt)
> >  (Estimated 1-2 months of work)
> >
> > The effort estimates are including time that is needed for fixing bugs
> and
> > do the testing.
> >
> > Vote for 1 if you like to see this implemented as part of OpenMeetings
> > 3.0.0, vote for Alternative 2 if you want to see this implemented as part
> > of OpenMeetings 3.0.0.
> >
> > Thanks,
> > Sebastian
> >
> >
> > 2013/8/8 seba.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
> > >
> >
> >
> >
> > --
> > 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: [VOTE] Discussing changes of Desing/Architecture of timezone implementation

Posted by Maxim Solodovnik <so...@gmail.com>.
I don't really like the idea of having setting in the options which is
overwritten on every login (silently)

My vote is for Alternative 2.

@Sebastian
I guess Alternative 2 is for 3.1.0? I can try to perform refactoring
faster. Then you can handle "fine tuning" of this issue and I can handle
Import/Export (might be tricky)


On Fri, Aug 9, 2013 at 2:24 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> So probably we can put this up for a vote?
>
> The only alternative I see as a short term fix is to overwrite the users
> "OmTimeZone" with the current timezone of the browser.
>
> Alternative 1:
> Short term fix, default OmTimeZone to current timezone in browser,
> overwrite everytime the user logs in (Estimated 1-2 weeks of work)
>
> Alternative 2:
> Rewrite and refactor to get rid of entire OmTimeZone (as described in
> attached discussion or thread:
> http://markmail.org/message/rem2snf74srvftnt)
>  (Estimated 1-2 months of work)
>
> The effort estimates are including time that is needed for fixing bugs and
> do the testing.
>
> Vote for 1 if you like to see this implemented as part of OpenMeetings
> 3.0.0, vote for Alternative 2 if you want to see this implemented as part
> of OpenMeetings 3.0.0.
>
> Thanks,
> Sebastian
>
>
> 2013/8/8 seba.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
> >
>
>
>
> --
> 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