Good point. If we need to cater for "the system" moving to a different timezone, then the "system common timezome" would need to be UTC not server-localtime.
Best regards Mike Burton On 15 Mar 2011, at 09:20, Alexander Krasnukhin wrote: > 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
