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

2013-08-09 Thread seba.wag...@gmail.com
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

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

2013-08-09 Thread seba.wag...@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 solomax...@gmail.com wrote: I don't really like the idea of having setting in the options

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

2013-08-09 Thread Maxim Solodovnik
OK let's wait for the VOTE results then start the refactoring :) On Fri, Aug 9, 2013 at 3:31 PM, seba.wag...@gmail.com seba.wag...@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

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

2013-08-09 Thread Vasiliy Degtyarev
My vote is for Alternative 2. Vasiliy On 09.08.2013 14:24, seba.wag...@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,

Jenkins build is back to normal : Red5 Trunk #264

2013-08-09 Thread Apache Jenkins Server
See https://builds.apache.org/job/Red5%20Trunk/264/changes

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

2013-08-09 Thread seba.wag...@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,

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

2013-08-09 Thread seba.wag...@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.wag...@gmail.com seba.wag...@gmail.com Maxim, just one thing: The new implemention will of course also silently overwrite the timezone string with

Re: Pull request to jquery-wicket-ui for fixing some API to be customizable

2013-08-09 Thread seba.wag...@gmail.com
Hi Sebastien, we opted now to refactor our code to always display the UI in the timezone of the browser, so we don't have this issue anymore. However I was looking at your code and realized that still there are a couple of issues that make it impossible to show the Calendar in any other timezone

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

2013-08-09 Thread seba.wag...@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:

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

2013-08-09 Thread seba.wag...@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().