> 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 :-) Actually, I don't think that's an issue. The reason we would specify the "server" time zone is not because we really want anything to be converted to the server time zone; rather, it's because using the server time zone avoids any conversion at all; if you're already in the time zone you're interested in (which would be the case if you explicitly specified the server time zone), then no conversion takes place. It doesn't matter how many servers are in how many time zones. - Brendan -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 2:44 PM To: MyFaces Discussion Subject: Re: curious problem with dates 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
