db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-601) Greater support is needed for the use the java.util.calendar class
Date Tue, 12 Jan 2010 19:36:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799342#action_12799342

Bryan Pendleton commented on DERBY-601:

Is the DERBY-651 support that is present in the trunk sufficient to provide this issue's 
requested "support to store and retrieve Calendar data types natively"? Or is there more 
work that needs to be done beyond what DERBY-651 provides?

> 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: Improvement
>          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.

View raw message