[
https://issues.apache.org/jira/browse/DERBY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651673#action_12651673
]
Dag H. Wanvik commented on DERBY-601:
-------------------------------------
+1 to close while we await JRS-310 outcome and its impact on JDBC.
> Greater support is needed for the use the java.util.calendar class
> ------------------------------------------------------------------
>
> Key: DERBY-601
> URL: https://issues.apache.org/jira/browse/DERBY-601
> Project: Derby
> Issue Type: Wish
> Components: Miscellaneous
> 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.
-
You can reply to this email to add a comment to the issue online.
