Proposed FormType changes

Christian and I have been talking about the addition of a new FormType 
for TIME and also some modifications to the existing DATE and TIMESTAMP 
type. I have attached to this email a patch that includes everything we 
have discussed if anyone else would like to provide some input. You can 
search for saw_061203_2 to see everything that has changed.


New FormType: TIME
==================
This is a new type that allows parsing of time values without any date 
component. This will return a java.sql.Time object since that is the 
only representation in the core Java packages for a type that is 
strictly time.

The parsing process will first try to parse as a long value 
(representing the time in milliseconds)... this makes it convenient to 
embed the time in a URL, for example. It will then try each of the 4 
time formats (SHORT, MEDIUM, LONG, FULL) and finally will try to parse 
from the SQL time format.


Changes to TIMESTAMP
====================
Timestamp has been modified to do exactly the same parsing steps as TIME 
except it will obviously be using the datetime parser 
(DateFormat.getDateTimeInstance) instead of the time parser. It will 
return an instance of java.sql.Timestamp (as it did before).


Changes to DATE
===============
I modified date so that it will also try the two new parsing steps 
referenced above (first try to parse a long; lastly try to parse from 
SQL date format). In any case it will still always return strictly a 
java.util.Date object.



Note that the changes to DATE may have broken some test cases as they 
report failures on my machine (TestDateValidator and 
TestDateRangeValidator). This is apparently because a date in the format 
"yyyy-MM-dd" is now considered valid when it wasn't previously. Can 
someone verify that?

What does everyone else think of this?

Thanks,
-shawn