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
