You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Travis Reeder <tr...@gmail.com> on 2005/10/14 23:13:06 UTC
Re: date conversion headache (HELP! URGENT!)
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 <us...@weber-oldenburg.de> wrote:
>
> Hi again :-).
>
> 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.
>
Re: date conversion headache (HELP! URGENT!)
Posted by Bruno Aranda <br...@gmail.com>.
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 <tr...@gmail.com>:
> 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 <br...@gmail.com> wrote:
> > We needed that in order to pass the TCK... otherwise myfaces would not
> > be certified :-(
> >
> > Bruno
> >
> > 2005/10/14, Travis Reeder <tr...@gmail.com>:
> > > 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 <ja...@mac.com> 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
> > > <us...@weber-oldenburg.de> 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/
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
Re: date conversion headache (HELP! URGENT!)
Posted by Travis Reeder <tr...@gmail.com>.
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 <br...@gmail.com> wrote:
>
> We needed that in order to pass the TCK... otherwise myfaces would not
> be certified :-(
>
> Bruno
>
> 2005/10/14, Travis Reeder <tr...@gmail.com>:
> > 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 <ja...@mac.com> 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
> > <us...@weber-oldenburg.de> 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/
> > >
> > >
> > >
> >
> >
>
Re: date conversion headache (HELP! URGENT!)
Posted by Bruno Aranda <br...@gmail.com>.
We needed that in order to pass the TCK... otherwise myfaces would not
be certified :-(
Bruno
2005/10/14, Travis Reeder <tr...@gmail.com>:
> 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 <ja...@mac.com> 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
> <us...@weber-oldenburg.de> 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/
> >
> >
> >
>
>
Re: date conversion headache (HELP! URGENT!)
Posted by Travis Reeder <tr...@gmail.com>.
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 <ja...@mac.com> 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 <us...@weber-oldenburg.de> 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/
>
>
>
Re: date conversion headache (HELP! URGENT!)
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
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 <us...@weber-oldenburg.de> 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/