[ http://issues.apache.org/jira/browse/DERBY-601?page=all ]
Daniel John Debrunner updated DERBY-601:
----------------------------------------
Component: Unknown
(was: SQL)
I think UNKNOWN is a good component for this, the problem being described is
not in the SQL language, it's move at the Java programming level. Really this
should be a bug entered against the JDBC spec at java.sun.com.
> Greater support is needed for the use the java.util.calendar class
> ------------------------------------------------------------------
>
> Key: DERBY-601
> URL: http://issues.apache.org/jira/browse/DERBY-601
> Project: Derby
> Type: Wish
> Components: Unknown
> Environment: Win XP Pro - Java 1.5.0
> Reporter: John Bush
>
> It appears as time goes on, the various DATE, TIME, and Timestamp classes are
> getting more difficult to work with. Not that they are rocket science, but
> there appears to be a race to deprecate some pretty basic functionality in
> the base classes that are not accounted for as you get further away from
> them.
> Cases in points would be if you want to duplicate a persisted timestamp (date
> and time with millisecond precision) from a dB. You can't create a natural
> statement such as 'Timestamp ts = new Timestamp(rs.getTimestamp("ts"));'
> since the only constructor not deprecated is 'Timestamp(long time)'. You are
> left with 'Timestamp ts = new Timestamp(rs.getTimestamp("ts").getTime());' or
> 'Timestamp ts = (Timestamp) rs.getTimestamp("updtTstamp").clone();' (assuming
> a simple object copy is appropriate and won't get bit doing a compare). It
> just as messy if you want to handle creating a Timestamp to persist, you are
> left with 'PreparedStatement ps.setTimestamp(1, new Timestamp(new
> Date().getTime()));'
> I realize that this issue mostly belongs to the java.sql.* group at Sun since
> they have chose not to provide anything to bridge their inheritance of
> deprecation, and also to the java.util.* group at Sun for being more
> interested in developing java.util.calendar than deprecating sensibly. It
> would be cool however if any dB vendor would take it upon themselves to
> provide support to store and retrieve Calendar data types natively, just like
> any other non simple data types.
> Thanks for your consideration - John Bush
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
