Hi Dan,
within...
> > I'm looking at defining an "application" timezone, but I'm not sure
> > where the best place is to define it.
> >
> That does seem like a useful concept.
>
> > ... The IsisSession has a getUserProfile, which has a
> > Localisation interface (which exposes a getTimeZone() method), but
> > this would possibly be the place to keep a per-user timezone, not an
> > application-level timezone [is this an artificial distinction?].
> >
> I think we *should* distinguish the two.
>
> As per the previous thread, I think that there are three clocks:
>
> - user timezone
> - app timezone (where the appserver runs)
> - db timezone.
>
> However, as your other thread said, java.sql.Date is meant to be a UTC
> date. So that simplifies things somewhat.
>
> - user timezone
> - app timezone (where the appserver runs)
> - db timezone = UTC
This is where I have found problems. The current issue *seems* to be
that when cal.getTime() is used to create a java.util.Date, it
automatically converts from cal's timezone to the system default.
> Moreover, some of these "cal" occur in the applib, which MUST
> NOT reference the runtime (IsisContext).
> ~~~
> As - again - you did note in your other thread, what's required is some
> sort of translation layer between the user timezone and UTC, and - again
> as you point out - org.apache.isis.adapters.Localization interface has
> this. This was something that Rob introduced about a month or go.
>
> I've just taken a look at how this interface is used it, it would seem
> to be used by ValueSemanticsProvider's Parser#displayTitleOf. In
> other words, this *is* the translation layer that you speak of (a Parser
> is used to render every value of every property of every object).
Is this layer used bi-di, i.e. all user text goes through it before getting to
the app layer, and vice versa?
> ~~~
> Putting all the above together:
>
> - let's agree that app server time = DB server time = UTC
I don't like this, because it means that in most of the simple
applications (where the app, users and DB are all in the same (non-
UTC) timezone), every date/time will be shunted back and forth
through timezone translations.
Also, are you suggesting that when Isis fires up, it automatically sets
the system default timezone to UTC? My gut feeling is that this would
be necessary for cal.getTime() to operate properly when used to
create a date.
Viz: I have a database field (of type DATE) which returns "2011-04-
08", or, in full, "2011-04-08T00:00:00.000+0200".
First question, what does +0200 mean, for a date, anyway?
Second question, since java.sql.Date is assumed to be UTC, why
does "rs.getDate(columnName);" return the "+0200" timezone?
Because the system default timezone is GMT+0200 on my machine!
Continuing: This java.util.Date date is used (in applib.value.Date) to
create a new internal java.util.date with the following: (note the
comment!)
public Date(final java.util.Date date) {
final Calendar cal = Calendar.getInstance();
cal.setTimeZone(UTC_TIME_ZONE);
// TODO when input date is BST then then date value ends up as
the previous day
cal.setTime(date);
cal.set(Calendar.HOUR, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
this.date = cal.getTime();
}
The "this.date" shows up in my system as:
"Thu Apr 07 14:00:00 SAST 2011" with a cdate of
"2011-04-07T14:00:00.000+0200"
It has moved back a day. And what is with the 14h00 time? It's a
*date* the time is supposed to be empty!
If I set the system default timezone to GMT-0200, then the end resut
reads "2011-04-06T22:00:00.000-0200"
I think java has messed up - java.util.Date has no explicit timezone (it
is managed via Calendar), but it has an implicit timezone based on the
system default?
I would like to look into Joda Time and see if they've fixed this issue.
> - the user timezone is as defined by Localization
> - the UI layer - by way of Parser interface - always (or should always)
> render the time with respect to the user's localization
> - we therefore shouldn't need any changes to the codebase.
>
> Where we currently have failing tests, it's probably because they are
> evaluating the date/time with respect to the timezone in which they are
> running, rather than UTC. In other words, the tests are at fault.
This is still possible (almost certain, in fact). I'm looking into it...
> ~~~
> Now, the above analysis may well be wrong, I haven't thought about this
> as much as you, but that's my initial stab on the matter.
>
> Let's keep this thread open until we get to a design that we are all
> happy with and understand.
One argument that I have against setting the system default (or the
app & datastore default) to UTC is that when looking at the raw data,
in a simple 1-timezone config, I want to see the values that I specified
(e.g. new applib.value.Date(2011, 4, 8), when written to the database,
appears as 2011-04-08 in my database browser).
