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
