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/
> >
> >
> >
>
>
