[jira] Resolved: (WW-3018) Type conversion for dates and doubles

["Musachy Barroso (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/WW-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Musachy Barroso resolved WW-3018.
---------------------------------

    Resolution: Duplicate

This is a know problem in 2.1.6 (in xwork 2.1.2 actually), see: http://jira.opensymphony.com/browse/XW-670

thanks for reporting.

> Type conversion for dates and doubles
> -------------------------------------
>
>                 Key: WW-3018
>                 URL: https://issues.apache.org/struts/browse/WW-3018
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Interceptors
>    Affects Versions: 2.1.6
>            Reporter: Tamas Ruff
>            Priority: Critical
>
> I have recently migrated from struts 2.0.11 to 2.1.6 and the type conversion does not work any more as expected for non-English locales. 
> Our application is localized (the locale is saved in the session under the default WW_TRANS_I18N_LOCALE key). 
> I would expect that the submitted date is parsed according to the SHORT format of the Locale saved in the session if the i18n interceptor precedes the params interceptor in the interceptor stack associated with the action. 
> For German locale I would expect to accept the dd.MM.yyyy pattern  (but it accepts only the MM/dd/yyy pattern).
> I should mention that I do not use the datetimepicker ajax tag from struts2, the date is submitted in the format entered by the user.
> The same problem for double numbers: on German locale I would expect to enter a decimal number like 1,2 instead of 1.2 but the corresponding double field will be set to 12 instead (I suppose the comma is considered thousand separator even if the locale is set to German). Moreover the 0 and negative numbers fail by type conversion even on English locale.
> For both cases (date and double) it seems that the params interceptor does not take into account the locale set in session even if i18n interceptor is called before params. 
> In the mail archive I found something similar with the datetimepicker but that is not my case because in my case the user entered value is submitted to the server directly (instead of some "standard" format). Is this a known problem and when yes is there some kind of patch/workaound available?

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