[jira] Commented: (WICKET-2841) DatePicker does not parse year with pattern dd.MM.yyyy correctly.

["Martin H. (JIRA)" <ji...@apache.org>]

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

Martin H. commented on WICKET-2841:
-----------------------------------

I can reproduce this bug. If i specify a format with just two digit year the java side seems to sanely interpret the 2 digit year. 
But the javascript part fails to respect 4 year date formats and just returns 2 digits which then gets misinterpreted as full year in the java part and the model ends up with dates < 100 year a.d. instead of in this or the last century.
so i think a better fix would be to explicitly check for both cases.

if(datePattern.match(/yyyy/)) {
   year=""+year;
   year = "0000".slice(0,4-year.length) + year;
} else if(datePattern.match(/yy/)) year = Wicket.DateTime.padDateFragment(year % 100); 

This should work for the common cases. (i.e. formated to 2 or 4 digits, year < 10000). But if required i should be able to write code that completly handles all valid cases. Also if need to fix this bug i can supply a real patch, but it shouldn't be much additional work to change this manually with help of the location information in the patch of the original reporter.

> DatePicker does not parse year with pattern dd.MM.yyyy correctly.
> -----------------------------------------------------------------
>
>                 Key: WICKET-2841
>                 URL: https://issues.apache.org/jira/browse/WICKET-2841
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-datetime
>            Reporter: Alf Støyle
>
> We use the date pattern dd.MM.yyyy, and when returning from the date picker (org.apache.wicket.extensions.yui.calendar.DatePicker) yields incorrect value in the date text field (org.apache.wicket.extensions.markup.html.form.DateTextField).
> For instance picking the date 19.04.2010 in the date picker, yields 19.04.10, which again becomes the java.util.Date 19.04.0010. We have found the source of the problem, and created a fix for this, but hopefully you can fix this in a later release, so we do not have to maintain a local patched version of wicket-datetime.
> I have included the patch here. However this code seems very intentional, so applying this patch may be breaking something else!?
> Thanks
> - Alf
> diff --git a/src/main/java/org/apache/wicket/extensions/yui/calendar/wicket-date.js b/src/main/java/org/apache/wicket/extensions/yui/calendar/wicket-date.js
> index 7f19c55..420f075 100644
> --- a/src/main/java/org/apache/wicket/extensions/yui/calendar/wicket-date.js
> +++ b/src/main/java/org/apache/wicket/extensions/yui/calendar/wicket-date.js
> @@ -134,7 +134,7 @@ Wicket.DateTime.substituteDate = function(datePattern, date) {
>         // optionally do some padding to match the pattern
>         if(datePattern.match(/dd+/)) day = Wicket.DateTime.padDateFragment(day);
>         if(datePattern.match(/MM+/)) month = Wicket.DateTime.padDateFragment(month);
> -        if(datePattern.match(/yy+/)) year = Wicket.DateTime.padDateFragment(year % 100);
> +       if(datePattern.match(/yy+/)) year = Wicket.DateTime.padDateFragment(year);
>         // replace pattern with real values
>         return datePattern.replace(/d+/, day).replace(/M+/, month).replace(/y+/, year);
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.