[jira] Commented: (TRINIDAD-61) tr:validateDateTimeRange validation fails on last day of valid range

["Yee-Wah Lee (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543965 ] 

Yee-Wah Lee commented on TRINIDAD-61:
-------------------------------------

This will be partially resolved by fix for JIRA Trinidad-748:
https://issues.apache.org/jira/browse/TRINIDAD-748

That fix uses the converter for both the value and the min/max values, so they all carry the same timezone offset and predefaulted values for h/m/s/ms.

However, the problem still remains on the server. The default value for the maxDate's h/m/s/ms is zero. However, there is code that copies over the h/m/s/ms from the existing value to the newly converted value (to avoid data loss when the converter shows only date). Thus, comparisons with the maxDate generally fail because the existing values are non-zero. The code that does this is: DateTimeConverter.java#_fillTimePortion()

> tr:validateDateTimeRange validation fails on last day of valid range
> --------------------------------------------------------------------
>
>                 Key: TRINIDAD-61
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-61
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>            Reporter: Thorsten Guenther
>         Attachments: screenshot-1.jpg
>
>
> When used without an given converter (tr:convertDateTime), a tr:validateDateTimeRange's javaScript-validation fails (when used with facelets? not tested.) if the last day of the valid date-range was choosen in the tr:inputDate. (see screenshot). Debugging the javaScript shows that the select date was converted into for example "20.09.2007 01:00:00" (depending on timeZone) and is checked against "20.09.2007 00:00:00". So the choosen date is bigger then the max date and the validation fails.
> Using a ValueBinding and setting the maxdate to "20.09.2007 23:59:59" does not solve the problem since the time component seems to be cut of from maxDate for javaScript validation.
> A <tr:convertDateTime pattern="dd.MM.yyyy"/> is a workaround.

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