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]
