Re: Proposed FormType changes

Do you think the Date issues will break existing applications the same way 
it broke the testcases?  Or were the testcases just being unnecessarily 
stringent on the date format?  "yyyy-MM-dd" is a valid date in my book.  If 
you don't forsee any (or rare) breakage of existing apps (mostly concerned 
about the Date as I don't think many have started using the Timestamp yet 
since it was only just introduced in 1.2.0), then I have no problem with 
it.  Christian or you can check it in.  Anyone else have opinions?

Jake

At 01:40 PM 6/13/2003 -0600, you wrote:
>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
>
>