Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Inconsistent results from convertDateTime in MyFaces 1.1 and MyFaces 1.2?  RSS feed

 
Eric Price
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've recently switched from JSF 1.1 to JSF 1.2 and am running into some apparent differences in the implementation of the convertDateTime component.

Here is the code snipit from the jsp:

<t:inputText binding="#{reportMgrBean.timeUpStartDateInput}" size="10" maxlength="10"
immediate="true" value="#{reportMgrBean.timeUpStartDate}" title="yyyy-MM-dd"
forceId="true" id="timeUpStartDateInput">
<f:convertDateTime type="date" pattern="yyyy-MM-dd"/>
</t:inputText>

<t:inputText binding="#{reportMgrBean.timeUpStartTimeInput}" size="8" maxlength="8"
immediate="true" value="#{reportMgrBean.timeUpStartTime}" title="HH:mm:ss"
forceId="true" id="timeUpStartTimeInput">
<f:convertDateTime type="time" pattern="HH:mm:ss"/>
</t:inputText>

I have the appropriate backing bean ReportMgrBean with the associated HtmlInput binding objects.
When I submit the page, I see different values for the date and time depending on which JSF version I'm using.

The date and time fields are set in the bean using the same java.util.Date instance as follows:


Calendar c = Calendar.getInstance( TimeZone.getTimeZone( "GMT" ) );

startDateInput.setValue( c.getTime() );
startTimeInput.setValue( c.getTime() );


Under MyFaces 1.1.4, Java 1.4, tomahawk 1.1.3 and assuming the date was 12:20:32 on Aug 4th 2009, I get:

date = '2009-08-04 00:00:00'
time= '1970-01-01 12:20:32'

So if I combine the two values, I end up with '2009-08-04 12:20:32', which is the correct submit date/time.

Under MyFaces 1.2.6, Java 1.5, tomahawk12-1.1.8, and assuming the same date/time values are set, I get:

date= '2009-08-04 12:20:32'
time= '1970-01-01 12:20:32'

So for some reason the converter on the "date" part is no longer zero-ing out the time fields, but the "time" converter IS zero-ing out the date fields. Can anyone else verify or have any ideas as to why this might be happening?

TIA.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's probably not a MyFaces issue. More likely a difference in the JSF standard itself. I'd RTFMs and see what they say.

Some word of advice, however. A rather vexing thing about JSF is that the timezone of the unqialified date is the server's timezone, not the client's, not GMT/UTC. So using a Calendar is futile.

Also, because constructor calls take a finite amount of time, I don't recommend getting the date twice. You risk things like having the time roll around between calls. A better practice would be:


Java has a long and unfortunate history of handling dates and times badly, especially in lack control of the precision of date/time objects. It can be especially problematic when saving and restoring dates to databases where what goes out isn't the same as what comes back.
 
Eric Price
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

After additional investigating, I agree that this is likely not an issue with MyFaces. I looked through the JSF standard and saw nothing that would imply a change in how the convertDateTime component handles the date/time parts. So I think it may just be a bug in the JSF reference implementation. I mean, I've seen some "interesting" changes, like the coersion of null or "" to 0, but I don't think they would suddenly say if the type is "date" now include the entire date, but if the type is "time" only include the time portion. At least I would hope not without some direct explanation as to why (which I didn't find).

I'm not concerned about the timezone issue, both server and client are on GMT time and the times are correct. And I'm not creating two separate date instances right after each other. My sample code shows me using the same Calendar instance, but what I really do is use a clone of the first Calendar such as the following:

So each converter is working on it's own separate Date instance.

Thanks for the suggestions/reply though.
 
Eric Price
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After several more iterations of testing, I discovered the problem is actually due to using the trinidad rendering kit. Part of my migration to 1.2 involved experimenting with use of the trinidad components. I thought I had removed all the trinidad stuff from my application during testing of this date problem, but I discovered that I had left the following in:

web-app library: trinidad-1.2.10
faces-config.xml
<default-render-kit-id>
org.apache.myfaces.trinidad.core
</default-render-kit-id>

once that was removed, along with the library, the application worked as expected. So it looks like the problem is with the trinidad rendering kit/library.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!