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
