[
https://issues.apache.org/jira/browse/TRINIDAD-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576377#action_12576377
]
Yee-Wah Lee commented on TRINIDAD-61:
-------------------------------------
I have found a case where the above changes are not adequate. On the
clientConvert demo:
http://www.irian.at/trinidad-demo/faces/convertValidate/clientConvert.jspx
<tr:inputText value="#{clientValidation.date}">
<tr:validateDateTimeRange minimum="2007-01-01"
maximum="2007-12-31"/>
</tr:inputText>
Suppose the server is running in America/Los_Angeles (UTC -8) , but has
timezone-id set to "Europe/Stockholm" (UTC+1). When running the demo above,
type the value "12/31/2007" and submit - it fails, returning with the error
message 'Date should be between 1/1/2007 and 12/31/2007'.
Debugging notes:
1. In TagUtils.java, the validator has its value set as "12/31/2007". It uses a
simple date format, with timezone set to Europe/Stockholm, to parse it to get
12/31/2007 00:00 (UTC+1) = 12/30/2007 15:00 (UTC-8) . It adds the time maximize
logic _after_ the date has been parsed, so in this case it adds 8h 59 min to
get 12/30/2007 23:59 (UTC -8) which is equivalent to 12/31/2007 8:59 (UTC +1).
2. When user submits "12/31/2007", the converter does String <-> Date
conversion. In the Trinidad DateTimeConverter#getAsObject(), it does the
following.
_getParsedDate:
- Creates a SimpleDateFormat with timezone (Europe/Stockholm) and the
type/pattern specified.
- Uses the SimpleDateFormat to parse the string "12/31/2007" - it gets
12/31/2007 00:00 (UTC + 1)
The next step is to ensure that time components aren't lost from the value just
because the converter doesn't display time (data loss). So:
_fillTimePortion:
- Gets the previous value and creates a Calendar object with timezone
Europe/Stockholm based on the time. Suppose the previous value was **** 22:43
(UTC+1) (The date doesn't really matter, it is going to copy the time
components in the next step).
- Copies the time components over to the new time. So,
Parsed Time = 12/31/2007 00:00 (UTC + 1)
Added Time components = 22 h 43 s
Return value = 12/31/2007 22:43 (UTC + 1)
3. Then, when the validator does the comparison, it throws a validation error
because it finds value > maximum
Value: 12/31/2007 22:43 (UTC + 1)
Maximum: 12/31/2007 11:00 (UTC + 1)
The clientConvert.jspx example prepopulates the value with the current
date-time, so this bug may not be occur when the current time is less than
((difference between timezone param and server timezone offset) - 1), or if
everything is running in the same timezone. It demonstrates a bug with the time
maximize logic, which should maximize the time before parsing, otherwise it may
add less than the range required to make validation pass.
> 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
> Assignee: Matthias Weßendorf
> Fix For: 1.0.5-core, 1.2.5-core
>
> Attachments: screenshot-1.jpg, trin11_61.diff, trin11_61_add.diff,
> trin12_61.diff, trin12_61_add.diff
>
>
> 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.
