[
https://issues.apache.org/jira/browse/TRINIDAD-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742888#action_12742888
]
Yee-Wah Lee commented on TRINIDAD-1550:
---------------------------------------
I think you are running into this portion of the code in trinidad-api
DateTimeConverter.java
/**
* Fill in the time portion of the new date with the time from the previous
* date value if the converter displays only date. For now, we are not
* bothered about filling all the missing parts of the pattern. But in
* future we would consider that.
*/
private void _fillTimePortion(
...
// convert the previous date value wrt client's timeZone
Calendar prevCal = Calendar.getInstance(timeZone);
prevCal.setTime(prevDate);
// convert the new date value wrt client's timeZone
Calendar newCal = Calendar.getInstance(timeZone);
newCal.setTime(newDate);
// extract all the missing time portions from the previous date value
// and set it to the new date value.
if (fillMilliSeconds)
{
newCal.set(Calendar.MILLISECOND, prevCal.get(Calendar.MILLISECOND));
}
if (fillSeconds)
{
newCal.set(Calendar.SECOND, prevCal.get(Calendar.SECOND));
}
..
If I am correct, the values that are being filled in (12:20:32) would vary each
time you run the application.
The scenario the code addresses is that the underlying Date has some
information (values for hour/min/sec/ms) but the converter is set to show date
only. If the user doesn't change anything and submits the page, if the
converter zeroed out the time portions, it would generate a value change even
though the user didn't explicitly change anything. The code is trying to avoid
the value change.
> convertDateTime handles type="date" incorrectly
> -----------------------------------------------
>
> Key: TRINIDAD-1550
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1550
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.10-core
> Environment: Linux 64-bit, Java 1.5.0_11
> Reporter: Eric Price
> Priority: Minor
>
> I have a backing bean that contains two HtmlInputText components. One stores
> the "date" part of a Date, the other stores the "time" part of a Date. When
> the user enters the information, the "date" and "time" are combined to form
> the actual Date.
> The bean has the following declarations:
> public class DateTestBean {
> private HtmlInputText dateInput = null;
> private HtmlInputText timeInput = null;
> private Date date = null;
> private Date time = null;
>
>
> public DateTestBean() {
> dateInput = new HtmlInputText();
> timeInput = new HtmlInputText();
>
> date = Calendar.getInstance( TimeZone.getTimeZone( "GMT" ) );
> time = (Date)date.clone();
> }
> }
> For my sample program, I have a button on the jsp that calls the action
> method setDateAction() to update the date/time values with current values.
> That method is shown below:
> public String setDateAction() {
> Calendar dateCal = Calendar.getInstance( TimeZone.getTimeZone( "GMT" ) );
> Calendar timeCal = (Calendar)dateCal.clone();
>
> dateInput.setValue( dateCal.getTime() );
> timeInput.setValue( timeCal.getTime() );
>
> date = dateCal.getTime();
> time = timeCal.getTime();
> return "success";
> }
> There is a corresponding action method associated with a submit button on the
> jsp that prints the date/time values when the page is submitted.
> public String displayDateAction() {
> Object valObj = this.dateInput.getValue();
>
> if (valObj instanceof Date) {
> System.out.println(" date=" + formatDate( (Date)valObj ) );
> }
>
> valObj = this.timeInput.getValue();
> if (valObj instanceof Date) {
> System.out.println( " time=" + formatDate( (Date)valObj ) );
> }
> }
> Here is the code snipit from the jsp:
> <t:panelGrid columns="2">
> <t:inputText binding="#{dateTestBean.dateInput}" size="10" maxlength="10"
> immediate="true" value="#{dateTestBean.date}" title="yyyy-MM-dd"
> id="dateInput">
> <f:convertDateTime type="date" pattern="yyyy-MM-dd"/>
> </t:inputText>
>
> <t:inputText binding="#{dateTestBean.timeInput}" size="8" maxlength="8"
> immediate="true" value="#{dateTestBean.time}" title="HH:mm:ss"
> id="timeUpStartTimeInput">
> <f:convertDateTime type="time" pattern="HH:mm:ss"/>
> </t:inputText>
> </t:panelGrid>
> <t:panelGrid columns="2">
> <t:commandButton value="Set Date" action="#{dateTestBean.setDateAction}"/>
> <t:commandButton value="Show Date"
> action="#{dateTestBean.displayDateAction}"/>
> </t:panelGrid>
> When I submit the page, I see different values for the date and time
> depending on whether or not I'm using the trinidad rendering kit.
> When the page loads the date and time fields are set to the correct "date"
> and "time" values. When the page is submitted, I see the following:
> Under MyFaces 1.1.4 (or JSF 1.1), Java 1.5, 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'
> Similarly, under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, tomahawk 12-1.1.8 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 when the page is submitted, I end up with
> '2009-08-04 12:20:32', which is the correct submit date/time.
> Under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, trinidad-1.2.10, 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 the convertDateTime with type="date" is not zero-ing out the time field
> values, but the one with type="time" is zero-ing out the date field values.
> I've done a lot of testing and originally thought the problem with with
> myFaces 1.2. But I eventually discovered that the problem occurs if I
> include the following in the faces-confg.xml regardless of whether or not I
> have any trinidad components in the page:
> <default-render-kit-id>
> org.apache.myfaces.trinidad.core
> </default-render-kit-id>
> This inclusion in the faces-config.xml also requires me to include the
> trinidad-1.2.10 libraries in my web app.
> Including these two items leads to the errant behavior of the convertDateTime
> with type="date" not zero-ing out the time fields of the date.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
