My point is that it's very common that development and production are in different timezones.
But I don't think UTC is a good choice. Try to write correct SQL queries developing in GMT+7 for production in GMT+2 while db stores everything in UTC. Happy testing! My point is that there must be one single place to take "system common time zone" from. And it should be as close as possible to the data - db is the perfect choice. With this approach even xml files must have "time zone" property so they will show correct time in GMT+2 and GMT+7. Well, it's just my thoughts. On Tue, Mar 15, 2011 at 10:52 AM, Mike Burton <[email protected]>wrote: > 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 > > -- Regards, Alexander
