Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <66109397.1227992084526.JavaMail.jira@brutus>
Date: Sat, 29 Nov 2008 12:54:44 -0800 (PST)
From: "John Bush (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-601) Greater support is needed for the use
 the java.util.calendar class
In-Reply-To: <795466810.1128496249806.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

John Bush commented on DERBY-601:
---------------------------------

Great plan, close this consideration and maybe the problem will go away. While you are at it maybe remove support for date without time and time without date since Java does not formally support them. The Derby community should show support for a sensible JSR-310 and be ready to implement its outcome. Closing this will just make that inevitability take longer.

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