Simon Kitching wrote:
Travis Reeder wrote:
This isn't expected behaviour, it's spec'ed behaviour. This tag is
special in my eyes because I think the spec is wrong and should change
and this tag is representative of what it should be. The behaviour
that Francesco is seeing is the same behaviour everyone is seeing and
I'm sure everyone wastes a lot of time trying to find a bug in their
own code when it turns out it's speced to be that way. Unless of
course you live in the GMT zone, but the world does not revolve around
that zone. ;)
Well, if you're writing a webapp that can be accessed from multiple
timezones then you need to handle this anyway; defaulting to the
timezone the server happens to be in won't work. The webapp needs to
specify a mapping that converts times to the timezone of the current user.
Maybe the default converter should output dates in a format that
includes the timezone info, though? Output like
12:00 Fri 15 October UTC
would be more helpful.
NB: While I haven't checked the spec, I presume that the Date output is
technically defaulting to the "UTC" timezone (Coordinated Universal
Time) which is the world standard timezone, not GMT. It just happens to
be the same as GMT (except that GMT has daylight saving while UTC does
not).
A couple more notes:
Some people have complained that JSF's spec requires the
f:convertDateTime class to "modify" the date to make it UTC. In fact,
the java.util.Date class always stores its date in UTC, as described in
the javadoc. It's just the DateFormat class which defaults to adjusting
its Date parameter for the local timezone before outputting a string
representing that Date.
More interestingly, what happens for a webapp running on servers
distributed across multiple timezones? This is quite common for serious
apps, for reliability purposes. It certainly isn't desirable for the
date shown in a page to change depending upon what server the response
came from :-)
I'm not saying that the s:convertDateTime class is a bad idea; many
webapps *will* only be running on servers in one timezone and having
users who are always in the same timezone. However I think the
s:convertDateTime documentation should describe clearly when that tag's
default is *not* a good idea...
Cheers,
Simon
