One thing that is not on our list now is the default timezone of the server.
Currently when you install OpenMeetings you choose a timezone.
The questions are:
1) Where do we populate the timezones from in that list, displaying 650
timezones of java.util.Timezone is not practical
2) If we default that timezone to some value, what shall it be? The
timezone of the server or the timezone of the client browser?
=> In theory this default timezone is used whenever we can't find a
suitable timezone. So potentially we can default it to the browsers
timezone that is currently installing OpenMeetings.
This default timzeone will be used whenever there is no timezone
available for a user or if the timezone of the user is corrupted.
Sebastian
2013/8/6 Maxim Solodovnik <solomax...@gmail.com>
> Additionally Appointment, I guess.
> Non-existent XML attribute will be ignored by simpleframework.
>
> I believe we can let timezones.xml live in our sources and convert backups
> based on it
>
>
> On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com <
> seba.wag...@gmail.com
> > wrote:
>
> > That might be another approach.
> > So you are saying we get rid of the Entity OmTimeZone in total?
> >
> > Even if we have the timezone in the each of those object,I think there
> > should be a fallback mechanism. Cause with every Java update (or I think
> > you can even do it manually) you can get updates to the number/offset of
> > the timezones (appearently every year such and such countries for
> instance
> > "decide" to switch to have not a Daylight saving time, et cetera, or
> there
> > is even a brand new timezone).
> > So it could happen one day that we have timezone string in our
> application
> > that is neither known to java.util.Timezone nor to
> > net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and
> does
> > not exist in the other.
> >
> > I think we should go the extra mile and try to outline the technical part
> > upfront doing anything concretly. It could save us a lot of time. Also it
> > might be good to discuss this publicly as more then one person can then
> > work on it in parallel.
> >
> > As far as I can judge you can't save the type java.util.Timezone in a
> > database.
> > So it has to be either a string or you store an Integer
> > (utcTimeZoneOffset). But I really don't like the latter as it does not
> > handle Daylight savings times.
> >
> > So the Entities that hold an attribute "omTimeZone" that would need to be
> > changed:
> > User
> > Invitations
> > MeetingMembers
> >
> > and they all get a new attribute "String tz"
> >
> > How would we imagine could the export and import work if you import an
> old
> > backup where the OmTimeZone is set in the user? I guess we need a
> converter
> > that can handle OmTimeZone to the new format.
> > However would that even work currently with
> > org.simpleframework.xml.Element, when you have an attribute that does
> just
> > no more exist ?
> >
> > Any other considerations that are not yet covered?
> >
> > Sebastian
> >
> >
> >
> >
> > 2013/8/6 Maxim Solodovnik <solomax...@gmail.com>
> >
> > > I like the idea of having less custom issues
> > > I believe TZ field in all our objects can easily be just a string like:
> > > "Europe/Berlin"
> > >
> > >
> > > On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik <solomax...@gmail.com
> > > >wrote:
> > >
> > > > I have: It is impossible to get User timezone (you only can get tz
> > shift
> > > > and/or dst shift and if dst is in effect)
> > > >
> > > > According to iCal4J time zone mapping I guess the name should be the
> > same
> > > >
> > > >
> > > > On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com <
> > > > seba.wag...@gmail.com> wrote:
> > > >
> > > >> Okay,
> > > >>
> > > >> after a bit of back and forth using the wicket-jquery-ui library I
> > think
> > > >> it
> > > >> might be worth re-evaluating our timezone behaviour.
> > > >>
> > > >> Basically it seems like the approach to show the UI in a timezone
> > > >> different
> > > >> from the users browser/os is a non common approach. And eventually
> we
> > > can
> > > >> directly migrate away from it.
> > > >>
> > > >> So the proposal would be:
> > > >> Show the calendar UI and any timezone relevant information in the
> > > >> browser's
> > > >> timezone.
> > > >>
> > > >> To resolve the issues in the invitations I would suggest the
> following
> > > >> changes:
> > > >> - When the user signs up the timezone is no more editable/not even
> > > shown
> > > >> maybe or read only and taken from the browser/client os
> > > >> - Everytime the user logs in the timezone field in the users
> profile
> > is
> > > >> updated with the current timezone of the browser/client os.
> > > >> The idea might be that we add a new entry in the table OmTimeZone
> > > >> whenever
> > > >> we detect any user with a new timezone.
> > > >> - Login view the Flash application will no more be possible. The
> > > >> Openlaszlo application will only be used for the conference room
> > itself
> > > >>
> > > >> By doing that it should basically all just work fine.
> > > >>
> > > >> But now comes the elefant :) We need a mapping between iCal4J
> > timezones
> > > >> and
> > > >> java.util.Timezone.
> > > >> iCal4J is using net.fortuna.ical4j.model.TimeZone and we only have
> > > >> java.util.TimeZones. This is the historical reason why the code is a
> > > >> little
> > > >> bit messed up with various timezone calculations and fallbacks.
> > > >>
> > > >> So it will be a major refactoring that should be planned and broken
> > down
> > > >> in
> > > >> several phases.
> > > >> We will change and touch all and any kind of functionality in
> > > >> OpenMeetings.
> > > >> It will require quite a bit of regression testing to check if
> nothing
> > is
> > > >> broken.
> > > >>
> > > >> We generall said refactorings like this are not part of OpenMeetings
> > > 3.0.
> > > >> And once we start this there is no way back. It will delay any
> > potential
> > > >> release by 1 - 2 months.
> > > >>
> > > >> What is the general opinion about this ?
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Sebastian Wagner
> > > >> https://twitter.com/#!/dead_lock
> > > >> http://www.webbase-design.de
> > > >> http://www.wagner-sebastian.com
> > > >> seba.wag...@gmail.com
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
> >
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wag...@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
