I have started a thread in Wicket-dev mailing list: http://wicket.markmail.org/thread/n6wlcov3ff6eq5t5 Will track it and maybe will propose the patch
On 22 July 2014 20:19, Maxim Solodovnik <solomax...@gmail.com> wrote: > I have sample code to determine which months/dates DST switch takes place > > https://svn.apache.org/viewvc/openmeetings/branches/3.0.x/src/main/webapp/js/openmeetings_functions.js?revision=1562780&view=markup > > line ~50 > The code might be enhanced to get actual hours DST switch taking place > > > On 22 July 2014 20:15, Robert EL <robesc...@gmail.com> wrote: > >> Thanks you, Maxim. >> >> I will create the quickstart, because the 6.16.0 version doesn't >> resolve the problem (it has the same code in the getTimeZone method). >> >> However, I think this problem is not easy to resolve, because this >> method return the best guess that wicket can do using the GMT and DST >> offset provided by the browser. >> >> Think in this case: >> >> 1. User is in the GMT-0 time zone. >> 2. Wicket list all the available time zone ID with the same GMT and >> DST offset. This is the list for GMT-0: >> >> Africa/Casablanca >> Africa/El_Aaiun >> Atlantic/Canary >> Atlantic/Faeroe >> Atlantic/Faroe >> Atlantic/Madeira >> Eire >> Europe/Belfast >> Europe/Dublin >> Europe/Guernsey >> Europe/Isle_of_Man >> Europe/Jersey >> Europe/Lisbon >> Europe/London >> GB >> GB-Eire >> Portugal >> WET >> >> 3. Wicket has to decide which is the correct time zone without other >> information. >> >> If you read the code of getTimeZone method you will see this comment: >> >> // this is a best guess... still the start and end of the DST should >> // be needed to know to be completely correct, or better yet >> // not just the GMT offset but the TimeZone ID should be transfered >> // from the browser. >> >> One solution could be identify the country of the user using his IP >> address. But databases are never perfect or user well could be a >> remote client of some provider from absolutely different time zone. >> >> Regards. >> >> 2014-07-22 12:46 GMT+01:00 Maxim Solodovnik <solomax...@gmail.com>: >> > I believe we should >> > 1) update to the latest 6.16.0 release >> > 2) In case still an issue file JIRA issue against WICKET: >> > https://issues.apache.org/jira/browse/WICKET >> > >> > Here is the small how-to >> https://wicket.apache.org/start/quickstart.html >> > create quick start >> > I believe this issue can be fixed in a day or so >> > >> > Could you create such quickstart? >> > >> > >> > On 22 July 2014 18:27, Robert EL <robesc...@gmail.com> wrote: >> >> >> >> Hi all, >> >> >> >> >> >> I'm using OM 3.0.3 and I've a problem when I create an event in the >> >> Scheduled Meeting. OM returns the fields StartDay and EndDay with one >> >> day less than the day selected (month view). >> >> >> >> >> >> I've had tracing the bug and I've found the problem in the method of >> >> detecting the time zone of the client. The method getTimeZone() of >> >> class ClientProperties (wicket-core-6.14.0.jar) always return the >> >> first time zone ID that match with the GMT and DST offset of the >> >> user's browser. >> >> >> >> >> >> In my case, it's returning “Africa/Casablanca” instead of >> >> “Atlantic/Canary”. “Africa/Casablanca” is the time zone of Morocco and >> >> it has a different daylight saving behavior from Jun 29 to July 28 >> >> (month of ramadan: >> >> >> >> >> http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html >> ). >> >> >> >> >> >> So, OM set StartDay and EndDay with one hour less when it applies this >> >> time zone to the day selected (these variables are initialized to >> >> 00:00:00 before apply the current time). >> >> >> >> >> >> Have you thought about adding a complementary method for guessing the >> >> TimeZone of the client? IP-based Geolocation, for instance?. Will OM >> >> continue using this method in future releases?. >> >> >> >> >> >> Regards. >> > >> > >> > >> > >> > -- >> > WBR >> > Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
