I have found a case where the above changes are not adequate. On the clientConvert demo:
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'.
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.
- 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:
- 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.