Serializing breaks for java.util.Date subclasses

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Serialize and deserialize a java.sql.Date, java.sql.Time, or 
java.sql.Timestamp
2. (e.g.) 
JsonReader.toJava("{\"@type\":\"java.sql.Date\",\"value\":1372136400000}") will 
return a java.util.Date rather than a java.sql.Date

What is the expected output? What do you see instead?
An instance of the respective java.sql.Date, java.sql.Time, or 
java.sql.Timestamp; instead you get a java.util.Date

What version of the product are you using? On what operating system?
2.0.1, Windows 7

Please provide any additional information below.

Since there is a specific reader/writer for java.util.Date, it handles the 
three subclass types as well but loses type specificity in the process.  A 
workaround is to provide custom readers/writers for the subclasses (these are 
highly redundant to the already existent java.util.Date reader/writer, however).

Original issue reported on code.google.com by dligh...@gmail.com on 13 Sep 2013 at 8:51

[GoogleCodeExporter]

Excellent find.  I will correct this and create a new release.  And I will 
create a test case for this specific issue.  

Original comment by jdereg@gmail.com on 15 Sep 2013 at 2:46

• Changed state: Accepted
• Added labels: OpSys-All, Usability

[GoogleCodeExporter]

This reported defect has been fixed.  java.util.Date, java.sql.Date, and 
java.sql.Timestamp all write out and read in correctly.  A stringent test case 
was added that tests these types by themselves, as members of an Object[], as 
members of a typed array, as Object fields, and as typed fields.

Original comment by jdereg@gmail.com on 15 Sep 2013 at 4:37

• Changed state: Done