Ok, I've had a little time to think some more about this while I was away.
Anyway, I realised a few things: 1) java.sql.Date is explicitly defined (in the Java docs) to be relative to GMT. Quote: "A thin wrapper around a millisecond value that allows JDBC to identify this as an SQL DATE value. A milliseconds value represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT. To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated. " The Hudson/Jenkins console output contains enough info to show the problem in all its glory: Test: testSqlDate() '2011-4-8' sqlDataClass.getSqlDate() as String:2011-04-06 sqlDate.toString() as String:2011-04-07 SQL date: Test '2011-4-8', expected 2011-04-07, and got 2011-04-06. This is with a GMT-0200 system default timezone! The date is supposed to be 8th of April, but displays as either the 7th or the 6th, depending on where in the code you inspect it! What am I missing? Time to dig a little deeper... 2) While I proposed to have "a database timezone", "an application timezone" and "a UI timezone", there is no clear separation between "system" and "user interface" in Isis. If all UI text passed through a common layer, then one would have an opportunity to "translate" datetimes,etc, for timezone. But this does not happen, does it? So, I suppose this means that ordinarily the only place that a timezone shift could occur is when datetimes transit in/out of the datastore! If you are writing an application with users in multiple timezones, you must manually manage storing the user's actual timezone and performing timezone shifts.
