So, to summarize, it sounds as though what we're all looking for is a way to parse and format dates without regard to the time zone; sometimes, they're just dates and times. So I guess the key here is *not* to default the time zone to something special, but rather to *ignore* the time zone completely (still retaining the capability to format and parse the dates).
- Brendan -----Original Message----- From: Travis Reeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 3:18 PM To: MyFaces Discussion Subject: Re: curious problem with dates Hi Simon, > > 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. No objections there, but defaulting to GMT won't work either. So in the case where you're not specifying the timezone for the user, what's the best timezone to use that won't cause so much confusion? > 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. The JSF spec problem is just a DateFormat thing too, it does not modify the actual Date object, it modifies the TimeZone in the formatter when parsing and formatting. Travis
