You can find it in the javadocs, which are considered part of the spec:
http://java.sun.com/j2ee/javaserverfaces/1.1/docs/api/javax/faces/convert/DateTimeConverter.html#getTimeZone()
Regards,
Bruno
2005/10/15, Travis Reeder <[EMAIL PROTECTED]>:
> That's absurd. If the timezone isn't specified, then TimeZone.getDefault()
> should be used shouldn't it? I see there is nothing in the spec with
> regards to this, but shouldn't the best and most reasonable default be used
> in this case? The fact that this thread and several others has even been
> started is a good indicator that what is currently happening is not what
> most people would expect and is therefore a bad thing. Even
> Calendar.getInstance() uses TimeZone.getDefault, so does the Calendar()
> constructor. (this isn't directed at you Bruno).
>
> Travis
>
>
>
>
> On 10/14/05, Bruno Aranda <[EMAIL PROTECTED]> wrote:
> > We needed that in order to pass the TCK... otherwise myfaces would not
> > be certified :-(
> >
> > Bruno
> >
> > 2005/10/14, Travis Reeder <[EMAIL PROTECTED]>:
> > > Good answer. ;) I think the way you specified is how most would
> expect it
> > > to be done and looks like it may have been that way before Sept. 5's
> checkin
> > > since it didn't default to GMT before then.
> > >
> > > Was:
> > > if (_timeZone != null)
> > > {
> > > format.setTimeZone(_timeZone);
> > > }
> > >
> > > Is:
> > > TimeZone tz = getTimeZone();
> > > if (tz != null)
> > > {
> > > format.setTimeZone(tz);
> > > }
> > > where getTimeZone() is:
> > > public TimeZone getTimeZone()
> > > {
> > > return _timeZone != null ? _timeZone : TIMEZONE_DEFAULT;
> > > }
> > > and TIMEZONE_DEFAULT is "GMT";
> > >
> > > Travis
> > >
> > >
> > >
> > >
> > > On 10/14/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
> > > > Because it is in the spec, or at least, the MyFaces people interpret
> > > > the spec that way.
> > > > Can we explain why it is in the spec that way? No. It probably has to
> > > > do with quantum logic or devine intervention or something (it makes no
> > > > sense).
> > > >
> > > > Anyway, with the complete experience we have now on the subject, we
> > > > know that the default should not be GMT, nor the system time zone
> > > > (which is a difficult concept for a webapp), but something else: null.
> > > > When a converter is used with timeZone="null", it should use the
> > > > timeZone of the provided Date to format, and the system timeZone in
> > > > parsing, creating a Date with the system timeZone. But the system time
> > > > zone only in the absence of a user timeZone, similar to the user
> locale
> > > > (to be set or gottten from the UIViewRoot).
> > > >
> > > > Anyway, to complete the story, setting timeZone="CET" on all
> converters
> > > > didn't really work in the end. Suddenly the reverse problem popped up,
> > > > and turned out to be that the tomcat user, under which the webapp was
> > > > deployed on a second server, had it's timeZone set to GMT. We ended up
> > > > creating a custom converter anyway, and the hell with the spec. Should
> > > > have done that much earlier.
> > > >
> > > >
> > > > On 14 Oct 2005, at 23:13, Travis Reeder wrote:
> > > >
> > > > > Can someone explain why the default will set the timezone to GMT
> > > > > rather than the system timezone as one would generally expect?
> > > > >
> > > > > Travis
> > > > >
> > > > > On 9/30/05, Volker Weber
> > > <[EMAIL PROTECTED]> wrote:
> > > > >>
> > > > >> After thinking about the GMT problem again i changed my mind.
> > > > >> The last weeks patch was the right way.
> > > > >>
> > > > >> And i also found the reason for the different behavior of
> h:inputText
> > > > >> and h:outputText in my example.
> > > > >> I was wondering why the h:outputText doesn't use a converter, but i
> > > > >> was
> > > > >> overlooking that the value of the h:outputText is not a Date
> object.
> > > > >> It's a String concatenated of two vb expressions.
> > > > >>
> > > > >> jsf spec says evaluation of those expression is made according to
> jsp
> > > > >> 2.0 spec. And jsp spec doesn't know anything about converters and
> > > > >> makes
> > > > >> just toString(). The Dates toString() uses system timeZone, and so
> i
> > > > >> got
> > > > >> this problem.
> > > > >>
> > > > >> So i split the h:outputText :
> > > > >>
> > > > >> <h:outputText
> > > > >> value="#{example_messages['date_comp_text6']} "/>
> > > > >> <h:outputText value="#{date3}">
> > > > >> <f:convertDateTime type="both"/>
> > > > >> </h:outputText>
> > > > >>
> > > > >> and got the expected output.
> > > > >>
> > > > >> Here i need to add the converter, because the default type is date
> > > > >> only.
> > > > >>
> > > > >> Regards
> > > > >>
> > > > >> Volker Weber wrote:
> > > > >> > Hi,
> > > > >> >
> > > > >> > the javadoc says:
> > > > >> > public java.util.TimeZone getTimeZone()
> > > > >> >
> > > > >> > Return the TimeZone used to interpret a time value. If not
> > > > >> > explicitly set, the default time zone of GMT returned.
> > > > >> >
> > > > >> > so we can't change this.
> > > > >> >
> > > > >> > but i think (now) the patch we applied last week was the wrong
> > > > >> solution.
> > > > >> >
> > > > >> > Instead of changing getAsString() to use getTimeZone() for
> setting
> > > > >> the
> > > > >> > timeZone to the DateFormat, getAsObject() shouldn't do this.
> > > > >> >
> > > > >> > Of cause getAsString() and getAsObject() must use the same
> TimeZone,
> > > > >> > which was not the case last week.
> > > > >> >
> > > > >> > The following is taken and light modified from date.jsp in simple
> > > > >> example:
> > > > >> >
> > > > >> > <h:inputText value="#{date3}">
> > > > >> > <f:convertDateTime type="both"/>
> > > > >> > </h:inputText>
> > > > >> > <f:verbatim><br></f:verbatim>
> > > > >> > <h:outputText
> > > value="#{example_messages['date_comp_text6']}
> > > > >> #{date3}"/>
> > > > >> >
> > > > >> > The time differs in <h:inputText ../> and <h:outputText ../>
> cause
> > > > >> of
> > > > >> > the GMT default in the converter. And around midnight also the
> date
> > > > >> may
> > > > >> > differ.
> > > > >> >
> > > > >> > I'm shure this is not the expected behavior. But i'm not shure if
> > > > >> this
> > > > >> > is not a problem in the h:outputText, shoudn't there also used
> the
> > > > >> > converter to convert the java.util.Date to string?
> > > > >> >
> > > > >> >
> > > > >> > But to be in sync with output generated by jsp the converter
> > > > >> shoudn't
> > > > >> > use getTimeZone() but _timeZone.
> > > > >> >
> > > > >> >
> > > > >> > We should undo the patch from last week and change getAsObject()
> > > > >> > accordingly.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > ir. ing. Jan Dockx wrote:
> > > > >> >
> > > > >> >>I believe the default is the cause of all problems. I think the
> > > > >> default
> > > > >> >>needs to be the systems time zone. But not sure yet.
> > > > >> >>
> > > > >> >>
> > > > >> >>On 29 Sep 2005, at 22:54, Mike Kienenberger wrote:
> > > > >> >>
> > > > >> >>This sounded vaguely familiar. I think it's been fixed.
> > > > >> >>
> > > > >> >>
> > >
> http://issues.apache.org/jira/browse/MYFACES-506?page=all
> > > > >> >> DateTimeConverter.getTimeZone should return the default time of
> > > > >> the
> > > > >> >>GMT zone by default
> > > > >> >>
> > > > >> >>
> > > > >>
> > > > >> --
> > > > >> Don't answer to From: address!
> > > > >> Mail to this account are droped if not recieved via mailinglist.
> > > > >> To contact me direct create the mail address by
> > > > >> concatenating my forename to my senders domain.
> > > > >>
> > > > Met vriendelijke groeten,
> > > >
> > > > Jan Dockx
> > > >
> > > > PeopleWare NV - Head Office
> > > > Cdt.Weynsstraat 85
> > > > B-2660 Hoboken
> > > > Tel: +32 3 448.33.38
> > > > Fax: +32 3 448.32.66
> > > >
> > > > PeopleWare NV - Branch Office Geel
> > > > Kleinhoefstraat 5
> > > > B-2440 Geel
> > > > Tel: +32 14 57.00.90
> > > > Fax: +32 14 58.13.25
> > > >
> > > > http://www.peopleware.be/
> > > > http://www.mobileware.be/
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
