Re: Discussing changes of Desing/Architecture of timezone implementation
I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be another approach. So you are saying we get rid of the Entity OmTimeZone in total? Even if we have the timezone in the each of those object,I think there should be a fallback mechanism. Cause with every Java update (or I think you can even do it manually) you can get updates to the number/offset of the timezones (appearently every year such and such countries for instance decide to switch to have not a Daylight saving time, et cetera, or there is even a brand new timezone). So it could happen one day that we have timezone string in our application that is neither known to java.util.Timezone nor to net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and does not exist in the other. I think we should go the extra mile and try to outline the technical part upfront doing anything concretly. It could save us a lot of time. Also it might be good to discuss this publicly as more then one person can then work on it in parallel. As far as I can judge you can't save the type java.util.Timezone in a database. So it has to be either a string or you store an Integer (utcTimeZoneOffset). But I really don't like the latter as it does not handle Daylight savings times. So the Entities that hold an attribute omTimeZone that would need to be
Re: Discussing changes of Desing/Architecture of timezone implementation
Can we define any useful JUnit tests so that we don't need to do so much manual testing ? I believe so, but what version will be affected with this change? 3.0.0 or 3.1.0? On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. ok Additionally Appointment, I guess. Nope, Appointment does not have timezone information. The start/end date of the appointment is always in the server time zone. Actually _an_ date/time that is stored is always the server time. We only need timezone information when we need to display that time for any _user_ to generate a localized representation of the date/time. For instance an Appointment can be 8am GMT but for one user 1am GMT/Berlin should be displayed as 6pm NZDT/Auckland and for yet another MeetingMember it has to be displayed as 2am EDT/New York. So from my point of view the User, MeetingMember and Invitations Entity are the right place. And that is already as it is now. So you can replace OmTimeZone in all those classes with the new attribute that stored the timezone. Can we define any useful JUnit tests so that we don't need to do so much manual testing ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be another approach. So you are saying we get rid of the Entity OmTimeZone in total? Even if we have the timezone in the each of those object,I think there should be a fallback mechanism. Cause with every Java update (or I think you can even do it manually) you can get updates to the number/offset of the timezones (appearently every year such and such countries for instance decide to switch to have not a Daylight saving time, et cetera, or there is even a brand new timezone). So it could happen one day that we have timezone string in our application that is neither known to java.util.Timezone nor to net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and does not exist in the other. I think we should go the extra mile and try to outline the technical part upfront doing anything concretly. It could save us a lot of time. Also it might be good to discuss this publicly as more then one person can then
Re: Discussing changes of Desing/Architecture of timezone implementation
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
Re: Discussing changes of Desing/Architecture of timezone implementation
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.comwrote: 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
Re: Discussing changes of Desing/Architecture of timezone implementation
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
Re: Discussing changes of Desing/Architecture of timezone implementation
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
Re: Discussing changes of Desing/Architecture of timezone implementation
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
Re: Discussing changes of Desing/Architecture of timezone implementation
The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.comwrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be another approach. So you are saying we get rid of the Entity OmTimeZone in total? Even if we have the timezone in the each of those object,I think there should be a fallback mechanism. Cause with every Java update (or I think you can even do it manually) you can get updates to the number/offset of the timezones (appearently every year such and such countries for instance decide to switch to have not a Daylight saving time, et cetera, or there is even a brand new timezone). So it could happen one day that we have timezone string in our application that is neither known to java.util.Timezone nor to net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and does not exist in the other. I think we should go the extra mile and try to outline the technical part upfront doing anything concretly. It could save us a lot of time. Also it might be good to discuss this publicly as more then one person can then work on it in parallel. As far as I can judge you can't save the type java.util.Timezone in a database. So it has to be either a string or you store an Integer (utcTimeZoneOffset). But I really don't like the latter as it does not handle Daylight savings times. So the Entities that hold an attribute omTimeZone that would need to be changed: User Invitations MeetingMembers and they all get a new attribute String tz How would we imagine could the export and import work if you import an old backup where the OmTimeZone is set in the user? I guess we need a converter that can handle OmTimeZone to the new format. However would that even work currently with org.simpleframework.xml.Element, when you have an attribute that does just no more exist ? Any other considerations that are not yet covered? Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com I like the idea of having less custom issues I believe TZ field in all our objects can easily be just a string like: Europe/Berlin On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik solomax...@gmail.com wrote: I have: It is impossible to get User timezone (you only can get tz shift and/or dst shift and if dst is in effect) According to iCal4J time zone mapping I guess the name should be the same On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: Okay, after a bit of back and forth using the wicket-jquery-ui library I think it might be worth re-evaluating our timezone behaviour. Basically it seems like the approach to show the UI in a timezone different from the users browser/os is a non common approach. And eventually we can directly migrate away from it. So the proposal would be: Show the calendar UI and any timezone relevant information in the browser's timezone. To resolve the issues in the invitations I would suggest the following changes: - When the user signs up the timezone is no more editable/not even shown maybe or read only and taken from the browser/client os - Everytime the user logs
Re: Discussing changes of Desing/Architecture of timezone implementation
I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be another approach. So you are saying we get rid of the Entity OmTimeZone in total? Even if we have the timezone in the each of those object,I think there should be a fallback mechanism. Cause with every Java update (or I think you can even do it manually) you can get updates to the number/offset of the timezones (appearently every year such and such countries for instance decide to switch to have not a Daylight saving time, et cetera, or there is even a brand new timezone). So it could happen one day that we have timezone string in our application that is neither known to java.util.Timezone nor to net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and does not exist in the other. I think we should go the extra mile and try to outline the technical part upfront doing anything concretly. It could save us a lot of time. Also it might be good to discuss this publicly as more then one person can then work on it in parallel. As far as I can judge you can't save the type java.util.Timezone in a database. So it has to be either a string or you store an Integer (utcTimeZoneOffset). But I really don't like the latter as it does not handle Daylight savings times. So the Entities that hold an attribute omTimeZone that would need to be changed: User Invitations MeetingMembers and they all get a new attribute String tz How would we imagine could the export and import work if you import an old backup where the OmTimeZone is set in the user? I guess we need a converter that can handle OmTimeZone to the new format. However would that even work currently with org.simpleframework.xml.Element, when you have an attribute that does just no more exist ? Any other considerations that are not yet covered? Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com I like the idea of having less custom issues I believe TZ field in all our objects can easily be just a string like: Europe/Berlin On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik solomax...@gmail.com wrote: I have: It is impossible to get User timezone (you only can get tz shift and/or dst shift and if dst is in effect) According to iCal4J time zone mapping I guess the name should be the same On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: Okay, after a bit of back and forth using the wicket-jquery-ui library I think it might be worth re-evaluating our timezone behaviour. Basically it seems like the approach to show the UI in a timezone different from the
Re: Discussing changes of Desing/Architecture of timezone implementation
I would default server time zone to the time zone of the server. It is up to admin to set it to the different value. On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: I basically don't mind about the component in the UI. I just thought initially that 650 in a combobox is too much. However it does not seem to be an issue for the UI as such. My basic question is what we use as default: Do we default to the server timezone or to the client site user timezone ? Sebastian 2013/8/7 Maxim Solodovnik solomax...@gmail.com The correct URL is http://timezonepicker.com/ On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik solomax...@gmail.com wrote: I believe we can use something like this: https://timezonepicker.com (sources are here: https://github.com/quicksketch/timezonepicker) The only issues I can see right now: 1) it has no License set in the moment ( https://github.com/quicksketch/timezonepicker/issues/2) 2) It last updated 9 months ago So maybe additional googling is required :) On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: One thing that is not on our list now is the default timezone of the server. Currently when you install OpenMeetings you choose a timezone. The questions are: 1) Where do we populate the timezones from in that list, displaying 650 timezones of java.util.Timezone is not practical 2) If we default that timezone to some value, what shall it be? The timezone of the server or the timezone of the client browser? = In theory this default timezone is used whenever we can't find a suitable timezone. So potentially we can default it to the browsers timezone that is currently installing OpenMeetings. This default timzeone will be used whenever there is no timezone available for a user or if the timezone of the user is corrupted. Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com Additionally Appointment, I guess. Non-existent XML attribute will be ignored by simpleframework. I believe we can let timezones.xml live in our sources and convert backups based on it On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com seba.wag...@gmail.com wrote: That might be another approach. So you are saying we get rid of the Entity OmTimeZone in total? Even if we have the timezone in the each of those object,I think there should be a fallback mechanism. Cause with every Java update (or I think you can even do it manually) you can get updates to the number/offset of the timezones (appearently every year such and such countries for instance decide to switch to have not a Daylight saving time, et cetera, or there is even a brand new timezone). So it could happen one day that we have timezone string in our application that is neither known to java.util.Timezone nor to net.fortuna.ical4j.model.TimeZone. Or a timezone exists in the one and does not exist in the other. I think we should go the extra mile and try to outline the technical part upfront doing anything concretly. It could save us a lot of time. Also it might be good to discuss this publicly as more then one person can then work on it in parallel. As far as I can judge you can't save the type java.util.Timezone in a database. So it has to be either a string or you store an Integer (utcTimeZoneOffset). But I really don't like the latter as it does not handle Daylight savings times. So the Entities that hold an attribute omTimeZone that would need to be changed: User Invitations MeetingMembers and they all get a new attribute String tz How would we imagine could the export and import work if you import an old backup where the OmTimeZone is set in the user? I guess we need a converter that can handle OmTimeZone to the new format. However would that even work currently with org.simpleframework.xml.Element, when you have an attribute that does just no more exist ? Any other considerations that are not yet covered? Sebastian 2013/8/6 Maxim Solodovnik solomax...@gmail.com I like the idea of having less custom issues I believe TZ field in all our objects can easily be just a string like: Europe/Berlin On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik solomax...@gmail.com wrote: I have: It is impossible to get User timezone (you only can get tz shift and/or dst shift and if dst is in effect) According to iCal4J time zone mapping I guess the name should be the same On Tue, Aug 6,
