[ 
https://issues.apache.org/jira/browse/WICKET-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004603#comment-13004603
 ] 

Bertrand Guay-Paquet commented on WICKET-3510:
----------------------------------------------

Thank you for the patch.

However, I found another problem in the Date conversion pipeline: 
        public void testStyleDateConverterTimeZoneDifference() throws 
ParseException
        {
                TimeZone origJvmDef = TimeZone.getDefault();
                DateTimeZone origJodaDef = DateTimeZone.getDefault();
                TimeZone tzClient = TimeZone.getTimeZone("Etc/GMT-14");
                TimeZone tzServer = TimeZone.getTimeZone("Etc/GMT+12");

                TimeZone.setDefault(tzServer);
                DateTimeZone.setDefault(DateTimeZone.forTimeZone(tzServer));
                Locale.setDefault(Locale.GERMAN);

                StyleDateConverter converter = new StyleDateConverter(true);

                Calendar cal = Calendar.getInstance(tzClient);
                cal.set(2011, 10, 5, 0, 0, 0);
                Date dateRef = cal.getTime();
                Date date = converter.convertToObject("05.11.2011", 
Locale.GERMAN);
                log.error("ref: " + dateRef.getTime() + "; converted: " + 
date.getTime());
                log.error("ref: " + dateRef + "; date: " + date);
                assertEquals(0, dateRef.compareTo(date));

                TimeZone.setDefault(origJvmDef);
                DateTimeZone.setDefault(origJodaDef);
        }

This means that the patch did solve part of the problem (double time zone 
conversion), but the converter is still broken.

What is the procedure for reopening an issue?

Also, is there a reason the test case method comment I submitted as part of the 
patch was removed? I thought it provided a clear explanation of why the test 
needed to be present.

> 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
>            Assignee: Igor Vaynberg
>              Labels: datepicker, datetime
>             Fix For: 1.5-RC3
>
>         Attachments: FailingTest.patch, TestDateConverter.java, 
> doubleConversionFix.patch
>
>
> 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

Reply via email to