Hi Kevin,
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.
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.
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.
All of the above should apply to Isis's "system run date" too.
Would JodaTime or somesuch help?
Best regards
Mike Burton
On 14 Mar 2011, at 16:10, Kevin Meyer - KMZ wrote:
> Hi guys,
>
> My old bug-bear is back!!
>
> I am experiencing some grief because the Isis applib Date, DateTime
> and java.sql.Date (and their value semantic providers) explicitly use an
> internal timezone of UTC.
>
> This impact on datastores or anyone creating a date directly.
>
> I've raised this before (a few years ago, if memory serve), but never
> reached a resolution..
>
> If the timezone is set to UTC, then all dates (and date times) seem to
> be interpreted as in this time zone. This causes problems for me, with
> my national (constant) GMT+2 offset, and anyone else not on GMT.
>
> One impact is that if I create a java.sql.Date, I must explicitly create it
> via a Calender with a UTC time zone. Simply creating a java.sql.date
> using "java.sql.date.valueOf("2010-03-05")" returns a value that does
> not compare with applib's Date.
>
> Another impact: Relative comparisons don't work!
> A simple proof (please check my logic): If I create an applib Date:
> Date applibDate = new Date(2010, 3, 5);
> and a DateTime:
> DateTime dateTime = new DateTime(2010, 3, 5, 1, 23);
> Then the comparison:
> dateTime.dateValue().after(date.dateValue())
> Fails, because I am at GMT+2!
>
> However, If I change the DateTime to 02h23, then it passes!
>
> This occurs because, deeper down, the Date value is stored (for me)
> as: 2010-03-05, 02h00
> I can get partial happiness with java.sql.Date if I remove the explicit
> setting of the time zone to UTC in the appropriate value semantic
> provider (JavaSqlDateValueSemanticsProvider), but then the xml
> object store breaks!
> By success, I mean that a new java.sql.Date of 3rd March has a cdate
> of "2010-03-05 0h00".
>
> People living in GMT will not be affected (until daylight savings time?)
>
> Symptomatically, this should mean that anyone with a timezone west
> of GMTcreating a applib date (or maybe just java.sql.date) should get
> a date of the previous day!
>
>
> In both the SQL and the XML object stores, dates are not stored with
> an explicit time zone (meaning, 2010-01-01 is 2010-01-01, whether
> you're in Japan or Hawaii), so you can't safely assume one?!?
>
> If you're writing an application that manages meetings (for example)
> and the participants span multiple time-zones, then I think you need to
> handle time zones specially carefully, and in your application/domain
> code?
>
> If you don't particularly care about comparing times that are (explicitly)
> in different time zones, Date, DateTime and java.sql.Date should just
> work!
>
> Comments anyone? Should Isis internal Dates (and DateTimes, etc)
> explicitly be based on a timezone set to UTC?
>
>
> Kevin
>
