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
