Sorry to interrupt you guys, but I have one simple question. I faced this problem before so I have something to say.
We need (db + server + client) to play. They are three distinct systems and each of them could be in different time zone. Right? So moving any of components to another time zone shouldn't change the app behavior, doesn't it? Otherwise you need to write a rule for any component relocation. For example if you choose server's time zone as default then moving server to another time zone automatically invalidates all data in the db. Even if you are using xml db the files written in GMT+2 is no valid for GMT+7. So you need to manually convert all dates for the new timezone. Really? Changing data only because of server relocation? On Tue, Mar 15, 2011 at 9:40 AM, Mike Burton <[email protected]>wrote: > Hi Kevin, > > > ...understand you correctly > Yes. > > > ...not UTC, prefer "system default". > I Agree. > > Before any calls to cal.getTime() including > the Isis applib when it calculates the Date / DateTime value, we'd need to > call cal.setTimezone() , maybe keeping a singleton 'cal' object too. > > Best Regards > > Mike Burton > ( iPhone) > > > > > On 15 Mar 2011, at 07:53, "Kevin Meyer" <[email protected]> wrote: > > > Hi Mike, > > > >> I think dates should be stored in the timezone where the app ie server > is > >> running, and every input or display should convert accordingly. > >> We should somewhere store / note the app / server's timezone, and never > >> change it. > > > > If I understand you correctly, what you're saying is equivalent to: > > a) Don't store the timezone with the date/time/datetime value, > > b) Assume the stored date/time/datetime is stored according to > > server defaults, > > c) Find the user timezone and convert date/time/datetime only as it > > transits the system <-> UI layer (i.e. only visually). > > > > The alternative to (c), which is to convert at the objectstore <-> > > system layer (i.e. all "internal" times are already converted to > > an appropriate timezone) I think is unworkable.. > > > > Anyone else? > > > > Perhaps an intermediate is to have a single static TimeZone instance > > provided by the framework (or whichever is most appropriate) context, > > that is set to what ever the application author desires - defaulting > > to "system default", instead of the local UTC timezone embedded in the > > applib Date/DateTime classes? > > > >> App would have to ascertain user's timezone (in user's preference page > >> etc?) , I don't think we can get this automatically like we can for > user's > >> locale. We could /guess/ that its different if we see that user's > /locale/ > >> is different to server's locale, then if we guess / suspect that it's > >> different we could prompt the user to specify their timezone in their > >> preference page. > > > > The user time zone would be stored in the user context, I guess... > > > >> In case of "raw" access to stored dates (or even in separate SQL > queries) > >> I can't see a way of enforcing this, but I guess such accesses would > >> mostly be done from the server ie in the server's timezone. > > > > This is why all stored data needs a common timezone, I'm just not sure > > it should explicitly be UTC. I think I prefer "system default". > > > > The issues seem to be that cal.getTime() [if memory serves] automatically > > translates the cal timezone from (in this case, UTC) to system default > > (for the returned Date). My cal.getTime() jumps 2 hours. > > If memory serves, it's the cal.getTime() method that is used to create > > the Isis applib Date / DateTime value. > > > >> All of the above should apply to Isis's "system run date" too. > >> > >> Would JodaTime or somesuch help? > > > > Is JodaTime[1] Apache compatible? Seems like: > > " Apache License > > Version 2.0, January 2004 > > http://www.apache.org/licenses/ > > "[2] > > > > Regards, > > Kevin > > > > [1] http://joda-time.sourceforge.net/ > > [2] http://joda-time.sourceforge.net/license.html > > > > > > -- Regards, Alexander
