[
https://issues.apache.org/jira/browse/TRINIDAD-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537462
]
Yee-Wah Lee commented on TRINIDAD-748:
--------------------------------------
Proposal : Send down min, max as Strings instead of millisecond Dates. Then,
use the client-side converter to create the Date objects from the Strings. That
way, the min/max/value will all be interpreted with the same client-converter
pattern and timezone offset.
> Client-side DateTimeRangeValidator does not handle differences in timezone
> --------------------------------------------------------------------------
>
> Key: TRINIDAD-748
> URL: https://issues.apache.org/jira/browse/TRINIDAD-748
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.2-core
> Reporter: Yee-Wah Lee
> Priority: Minor
>
> Scenario: I'm using a DateTimeRangeValidator on an inputDate, with minimum
> bound to a Date, say, since today at midnight (Oct 1 2007 12:00:00 AM). The
> server is running in local time (Pacific/Los_Angeles). The client is
> running in America/New_York timezone.
> If client-side validation is disabled, the user can enter a string like "Oct
> 1 2007 12:00:01 AM" and that will submit successfully since the string is
> interpreted into the server's timezone and it is indeed greater than today's
> midnight.
> If client-side validation is enabled, the same string will fail. The error
> message is "Enter a date greater than or equal to Oct 1 2007 3:00:00 AM".
> This is because the client-side validator is interpreting the value in the
> local timezone, so "Oct 1 2007 12:00:01 AM EST". That is earlier than "Oct 1
> 2007 12:00:00 AM PDT", so it fails validation.
> The net result is, the values accepted are dependent on client-side
> validation being enabled, and whether the timezone adds/subtracts from the
> value so that it still falls within range.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
