On 29 Sep 2005, at 22:54, Mike Kienenberger wrote:
This sounded vaguely familiar. I think it's been fixed.<x-tad-smaller>Met vriendelijke groeten,
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 :)Met vriendelijke groeten,
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:Met vriendelijke groeten,
<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.value="#{enrollmentH.instance.startDate}" /><br />
We have this jsf code:
1: <h:outputText
<f:verbatim>2: ${enrollmentH.instance.startDate}<br/></f:verbatim>
<x:inputText id="startDate"value="#{enrollmentH.instance.startDate}"
required="true"enrollmentH.showFields}"
size="10"
maxlength="10"
displayValueOnly="#{not
displayValueOnlyStyleClass="#{enrollmentH.viewMode}">
<f:convertDateTime pattern="dd/MM/yyyy" />2005.
</x:inputText>
(ok, it's hacked)
the enrollmentH.instance.startDate is a java.util.Date, 1 september
What is shown istrunk, 2005-09-28, 11:00am CET.
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
What are we missing????
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/
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/
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
