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
On 9/29/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
> Indeed. Did that of course (10 hours ago). And the code of
> DateTimeConverter looks perfectly ok. It doesn't do anything, really,
> just delegating to java.text.DateFormat!
>
> If there is a time zone, it is set on the DateFormat, if not, it is
> left alone.
>
> .....
>
> wait a sec
>
> public TimeZone getTimeZone()
> {
> return _timeZone != null ? _timeZone : TIMEZONE_DEFAULT;
> }
>
> getTimeZone() nevers return null! And the TIMEZONE_DEFAULT is GMT.
>
>
> And only people on the east side of Greenwich will see this problem! So
> that's why there is almost no discussion of this issue! You are all in
> the UK, Ireland or the US!
>
>
> TUUUUUUUUT
>
>
> Ok. This can't be right, is it? This just confirms, to a degree, my
> previous reasoning. Still not sure that it covers everyting, though.
> The questions remain:
>
> * The time zone stuff is surprising at least. The default should be
> that in all instances a raw Date is interpreted the same, not as GMT in
> one case, and as GMT+2 in another. This can't be in the spec's like
> this, can it?
> * If it is in the spec's: I am missing something. It can be necessary
> to repeat the time zone in all tags! Is there a general setting in
> faces-config.xml or web.xml or something I don't know about?
> * The inconsistency between parsing and rendering must be a bug, no?
>
>
> What does the spec say about this? Shouldn't we just delete this
> DEFAULT TIMEZONE stuff? And what about the inconsistency.
>
>
>
> On 29 Sep 2005, at 22:29, Mike Kienenberger wrote:
>
> > When all else fails, step through the source and see what's going on :)
> >
> > On 9/29/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
> >> Right, will try that.
> >>
> >> But hey, list, I need some more feedback here :-]. This is killing me.
> >> This cannot be right. I must be doing something wrong.
> >>
> >> Ok, here is my reasoning. Please tell me if you agree:
> >>
> >>
> >> I have a java.util.Date (hence forward called Date). Date doesn't know
> >> didley about time zones. This date is just 1 september 2005, sec (so
> >> 00:00h).
> >>
> >> Now I suppose (please comment !) that JSF convertDateTime is "time
> >> zone" aware. It finds out somehow that this computer is running in
> >> Belgium, and that we are (daylight savings time) actually on GMT+2.
> >> Given no more directions, it seems to want to render the Date in GMT
> >> as
> >> default. So, it says "hey, it's 31 august, 22:00h", presuming that the
> >> Date it got to render is actually in the time zone of the machine.
> >>
> >> When I change the code, and add <f:convertDateTime type="both"
> >> timeZone="GMT+2" ... />, the converter reasons "I get a Date from time
> >> zone GMT+2, and this guy wants me to render it in time zone GMT+2",
> >> and
> >> does ok.
> >>
> >> Ok, that's all speculation, because I really don't know.
> >>
> >> Now the serious issue is that if this is used in an input text. The
> >> rendering is the same in outputText and inputText. But if a user
> >> enters
> >> "1/9/2005", this actually translates into a Date in the DB that is
> >> 1/9/2005, 00:00h, without the time zone setting, and with the time
> >> zone
> >> setting. (to DB using Hibernate 'date', meaning time part is always
> >> oo:00h). Tuuuuuuuuuuuuuuuuuuuuuuuut.
> >>
> >> The net effect is that users enter data ok. Stuff is saved. If later
> >> they edit other fields of the record, the "day early" value is shown
> >> in
> >> the date inputText. User is not looking there, and is unaware of the
> >> "feature". The user is focussing on other fields (he only wants to
> >> correct the last name). He does so, and hits submit. NOW THE DAY EARLY
> >> VALUE IS BEING WRITTEN TO THE DB!!! And if this is repeated, each time
> >> the date is counting down.
> >>
> >>
> >>
> >> Ok. This must be a bug, no?
> >> * The time zone stuff is surprising at least. The default should be
> >> that in all instances a raw Date is interpreted the same, not as GMT
> >> in
> >> one case, and as GMT+2 in another. This can't be in the spec's like
> >> this, can it?
> >> * If it is in the spec's: I am missing something. It can be necessary
> >> to repeat the time zone in all tags! Is there a general setting in
> >> faces-config.xml or web.xml or something I don't know about?
> >> * The inconsistency between parsing and rendering must be a bug, no?
> >>
> >>
> >> But on the other hand, this is so blatant, and there is nothing on
> >> this
> >> in this mailing list I can remember or find, and I couldn't find
> >> anything relevant in the JIRA, so it must be me being very tired
> >> (deployment stress :-$).
> >>
> >>
> >> I'm getting totally twisted and paranoid. Please set me straight.
> >>
> >>
> >> On 29 Sep 2005, at 19:11, Matt Blum wrote:
> >>
> >>> Try changing the convertDateTime tag thusly:
> >>>
> >>> <f:convertDateTime pattern="dd/MM/yyyy" timeZone="CET" />
> >>>
> >>> -Matt
> >>>
> >>> On 9/29/05, Jan Dockx <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> Submitting data works ok: if I enter 1/9/2005 in the entry field,
> >>>> the
> >>>> DB ends up with 1/9/2005, 0:00h. So the MyFaces DateTimeConverter
> >>>> converts ok. So far so good. Data that comes from the DB creates a
> >>>> java.util.Date that is 1/9/2005, 0:00h. Ok. When I show it with JSP
> >>>> EL, I see 1/9/2005. Ok. When I show that Date with JSF however, it
> >>>> shows 31/8/2005 23:00h! When I add timeZone="GMT+2", it renders
> >>>> 1/9/2005. We are in Belgium, daylight saving time is active, and we
> >>>> are in GMT+1.
> >>>>
> >>>> At least, this is inconsistent behavior. And frankly, looking at the
> >>>> code of DateTimeConverter, I don't get it.
> >>>>
> >>>>
> >>>>
> >>>> On Thursday, September 29, 2005, at 05:28PM, Jan Dockx <
> >>>> [EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> I'm getting tired.
> >>>>>
> >>>>> We have this jsf code:
> >>>>>
> >>>>> 1: <h:outputText
> >>>> value="#{enrollmentH.instance.startDate}" /><br />
> >>>>> <f:verbatim>2: ${enrollmentH.instance.startDate}<br
> >>>> /></f:verbatim>
> >>>>> <x:inputText id="startDate"
> >>>>>
> >>>> value="#{enrollmentH.instance.startDate}"
> >>>>> required="true"
> >>>>> size="10"
> >>>>> maxlength="10"
> >>>>> displayValueOnly="#{not
> >>>> enrollmentH.showFields}"
> >>>>>
> >>>> displayValueOnlyStyleClass="#{enrollmentH.viewMode}">
> >>>>> <f:convertDateTime pattern="dd/MM/yyyy" />
> >>>>> </x:inputText>
> >>>>>
> >>>>> (ok, it's hacked)
> >>>>>
> >>>>> the enrollmentH.instance.startDate is a java.util.Date, 1 september
> >>>> 2005.
> >>>>>
> >>>>> What is shown is
> >>>>>
> >>>>> 31-aug-2005
> >>>>> 2: 2005-09-01
> >>>>> 31/08/2005?
> >>>>>
> >>>>> in other words:
> >>>>>
> >>>>> h:outputText rendes 31 august
> >>>>> JSP el renders 1 september
> >>>>> h:inputText renders 31 august
> >>>>>
> >>>>> JSF is one day off!!!
> >>>>>
> >>>>> It's probably our fault. We are using a custom build of the main
> >>>> trunk, 2005-09-28, 11:00am CET.
> >>>>> What are we missing????
> >>>>>
> >>>>>
> >>>>
> >> 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/
> >>
> >>
> >>
> 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/
>
>
