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 > >
