java.util.Date is actually container for "milliseconds from 01.01.1970" :))
On Sun, Aug 11, 2013 at 11:50 AM, seba.wag...@gmail.com < seba.wag...@gmail.com> 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 <seb...@gmail.com> > >> 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, seba.wag...@gmail.com < >> seba.wag...@gmail.com> 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 > seba.wag...@gmail.com > -- WBR Maxim aka solomax
