[
https://issues.apache.org/jira/browse/WICKET-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004064#comment-13004064
]
Andera Del Bene commented on WICKET-3510:
-----------------------------------------
I think I've found where is the problem. Time zone conversion of user input is
performed twice: the first time in DateTextField control and the second time in
method DateTimeField#convertInput().
That's because in method DateTimeField#newDateTextField we build a
DateTextField with a date converter which take into account time zone
difference between the server and the client.
The problem arises only when client and server have a different date at the
same time (like in your test). That's why existing test method 'test3' doesn't
fail.
I've attached a patch that solve this problem. It modifies method
DateTextField#forShortStyle adding a boolean flag that switches on/off time
zone conversion.
> DateTimeField improperly converts time causing wrong dates when the server's
> current date is different from the client's date.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3510
> URL: https://issues.apache.org/jira/browse/WICKET-3510
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.5-RC2
> Reporter: Bertrand Guay-Paquet
> Labels: datepicker, datetime
> Attachments: FailingTest.patch, TestDateConverter.java
>
>
> The bug is in DateTimeField#convertInput().
> <code>
> // Get year, month and day ignoring any timezone of the Date object
> Calendar cal = Calendar.getInstance();
> cal.setTime(dateFieldInput);
> int year = cal.get(Calendar.YEAR);
> int month = cal.get(Calendar.MONTH) + 1;
> int day = cal.get(Calendar.DAY_OF_MONTH);
> int hours = (hoursInput == null ? 0 : hoursInput % 24);
> int minutes = (minutesInput == null ? 0 : minutesInput);
> // Use the input to create a date object with proper timezone
> MutableDateTime date = new MutableDateTime(year, month, day, hours, minutes,
> 0, 0,
> DateTimeZone.forTimeZone(getClientTimeZone()));
> </code>
> If the server's current date is different from the client's, this produces
> wrong output. I attached a patch with a test case that simulates this
> condition.
> I don't know why this "casting" of day, month, year is done.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
