Hi Maxim, Sebastian, Sorry to wake up this thread...
I have a todo for wicket-jquery-ui 6.11.0 which is to (maybe) restore CalendarModelBehavior#newRequestHandler() visibility to private (instead of protected). I don't think you had to override it, but could you just double check? If it is not the case (I mean you did not override it), I think it should remains for internal/private use... Your thought/opinion is welcome, of course. Thanks in advance & best regards, Sebastien. On Mon, Aug 12, 2013 at 5:45 AM, Maxim Solodovnik <[email protected]>wrote: > java.util.Date is actually container for "milliseconds from 01.01.1970" :)) > > > On Sun, Aug 11, 2013 at 11:50 AM, [email protected] < > [email protected]> wrote: > >> Hi Sebastien, >> >> thanks for those updates, I don't think we require anything from your >> side at the moment. >> >> About *storing in a GMT (or UTC ... )* >> Basically you can't store any kind of TimeZone information together with >> the Date object in a database. >> If you try to save an object java.util.Date or java.util.Calendar in a >> database it will simply cut away the timezone information. This behaviour >> is the same across all major database vendors, so that even ORMs like >> OpenJPA do note it their docs: >> >> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/ref_guide_pc_scos.html#ref_guide_pc_calendar_timezone >> >> The reason for that is that databases only have the field dateTime which >> is YYYY-MM-DD HH:MM:SS.sss >> There is no space reserved in the database for the timezone. >> >> So the general solution might be that the date that you store in the >> database is always in the timezone of the (database) server. (And it makes >> a lot of sense to have database server and application server in the same >> timezone). >> If you mix the date/times in your database to store some in UTC and some >> in local time, simply queries might just return wrong values as the >> database does not know that it needs to consider the timezone different >> between certain fields. >> So I am not saying that nobody might save the dateTime in GTM or UTC in a >> database but whom-ever does it might create more issues then solving. >> I have seen a couple of such things, for instance in the PHP world it >> seems quite common that you convert everything into milliseconds since 1970 >> instead of using appropriate date/time database fields :))) >> >> Just my 2 Cents :) >> >> Sebastian >> >> >> >> 2013/8/10 Sebastien <[email protected]> >> >>> Hi Sebastien, >>> >>> >>> > newRequestHandler() should be public, otherwise you can't modify the >>> output really. >>> Well... I should have thought about this ;) But maybe you do not have to >>> override it, please see bellow... >>> >>> >>> >>> >What was your major idea about timezone safe Calendar, is the basic >>> idea that every date/time on server side is always handled as if its in the >>> timezone of the server? So in other words: Any incoming date/time has to be >>> converted into the timezone of the server first, before doing anything with >>> it? >>> >>> I did not had a precise idea on this because there is many way to >>> achieve this and I do not know your usecases/contraints exactly. But, if I >>> had to implement this, I would have l explored several ways: >>> >>> At a first point, the strategy: should the *all* events be stored in a >>> GMT (or UTC, Coordinated Universal Time) timezone, or should they be stored >>> with the "correct" time with the user's timezone information. That's may be >>> a strange question but I am pretty sure google's calendar opted for the >>> first strategy. Then, it is easier to slice/display the same event in >>> different timezone. >>> >>> The second point, is how the user timezone is handled. Or the timezone >>> information is sent by the browser or it is stored with the user account >>> (server side then)? Or you have a mix of both (the best). In my POV, the >>> timezone to be used is the one stored with the user account. But, you can >>> also use the browser's timezone to compare if both are the same. If not, >>> you can display a message like "Hey, your timezone is currently set to >>> Paris/France, but it seems that you are now in Tokyo/Japan, do you wish to >>> update your timezone?". >>> >>> Then the third point, when (at that stage) the timezone information >>> should be used/applied? Should the timezone be used to retrieve the events >>> or should it be used to slice event dates after there have been retrieved, >>> in a GMT/UTC format? Probably both, depending of choices in point #1 & #2, >>> you may convert the user timezone to GMT/UTC, query the DB, and then slice >>> events to the user timezone. In that case, the first conversion should be >>> done in CalendarModelBehavior. But there is not need to rewrite >>> #newRequestHandler for this. If I supply a protected >>> CalendarModelBehavior#setStartDate/setEndDate(model, date) you are be good >>> enough with that. To slice the events to the user timezone after the >>> events-load, if CalendarModel extends ICalendarVisitor then it is easy to >>> update the event dates according to the user timezone. >>> >>> I do not pretend it is the solution you have to put in place, maybe I >>> miss something according to your usecases/contraints, but that's the way I >>> would have think about this... >>> >>> >>> > I also see that you finetune the access rights on class and method >>> level quite heavily. >>> Yes, exactly to prevent user to miss-use the API. I agree that you may >>> have some flexibility in your case. But depending of your choices, maybe >>> you will *not* have to override #newRequestHandler >>> >>> >>> So, I: >>> - changed #newRequestHandler visibility to protected >>> - changed CalendarModel#setStart & CalendarModel#setEnd visibility to >>> public >>> - added CalendarModelBehavior#setStartDate & >>> CalendarModelBehavior#setEndDate(model, date) >>> - deployed 6.9.2-SNAPSHOT >>> >>> Please tell what you think about this (if my explanations was clear >>> enough ;)) >>> I will probably release 6.9.10 in the coming days (next friday at >>> latest), so if you need something else, that's the good moment... >>> >>> Best regards, >>> Sebastien >>> >>> >>> >>> >>> On Sat, Aug 10, 2013 at 1:38 AM, [email protected] < >>> [email protected]> wrote: >>> >>>> 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 then user or the server timezone: >>>> In the class CalendarModelBehaviour the method: private IRequestHandler >>>> newRequestHandler() >>>> should be public, otherwise you can't modify the output really. >>>> >>>> That is the major issue. >>>> >>>> What was your major idea about timezone safe Calendar, is the basic >>>> idea that every date/time on server side is always handled as if its in the >>>> timezone of the server? So in other words: Any incoming date/time has to be >>>> converted into the timezone of the server first, before doing anything with >>>> it? >>>> >>>> I also see that you finetune the access rights on class and method >>>> level quite heavily. >>>> Often classes are protected private or just private. For instance the >>>> methods setStart/setEnd in the CalendarModel. >>>> Having those finetuned access rights on an API is basically a good >>>> thing cause you can modularize your components and integrators only use the >>>> desired APIs, so you can change the core without affecting others. But its >>>> quite easy to overachieve that goal. >>>> >>>> Happy to hear more from your side, great work with that component! >>>> >>>> Cheers! >>>> Sebastian >>>> >>>> >>>> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax >
