[ tapestry-Feature Requests-648435 ] Using java.util.Date in DatePicker

Feature Requests item #648435, was opened at 2002-12-04 15:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354754&aid=648435&group_id=4754

Category: framework
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Adam Greene (ccm682)
Assigned to: Malcolm Edgar (malcolm_edgar)
Summary: Using java.util.Date in DatePicker

Initial Comment:
Currently the DatePicker utilizes java.sql.Date as it's 
expected source for the date value, which causes 
problems.  You cannot hand it a java.util.Date or a 
java.sql.Timestamp.  If it was made to use java.util.Date 
then you could hand it a java.sql.Date, a 
java.sql.Timestamp or a java.util.Date.  Which would be 
more flexible. 

The reason I suggest this is that we use Torque for our 
O/R bindings and we are allows having to create extra 
methods to create a java.sql.Date object and copy the 
java.sql.Timestamp into it.

----------------------------------------------------------------------

>Comment By: Neil Clayton (scornflake)
Date: 2002-12-09 21:46

Message:
Logged In: YES 
user_id=60452

I've find the existing typing good - perhaps because I'm not 
constrained by anything (I was able to make my persisted 
types the SQL ones, rather than using java.util.Date).   Is there 
a way to make the component handle both (rather than 
breaking existing code?) 
 
Two date properties? (hmm. might be a bit of a kludge). A 
"date" property taking a java.lang.Object, but throwing an 
exception if it's not one of the SQL date/timestamp or a 
java.util.Date? (less of a kludge, still safe, but not quite as 
pretty) 

----------------------------------------------------------------------

Comment By: Adam Greene (ccm682)
Date: 2002-12-05 20:49

Message:
Logged In: YES 
user_id=659256

The problem we run into that our database software return a 
java.util.Date, but in actuality assigns a java.sql.Timestamp 
to that java.util.Date and when we try to pass it to the 
DatePicker, it throws a ClassCastException as Timestamp 
and sql.Date are direct descendants of java.util.Date (which 
means they are not polymorphically compatible).

----------------------------------------------------------------------

Comment By: Malcolm Edgar (malcolm_edgar)
Date: 2002-12-04 22:08

Message:
Logged In: YES 
user_id=592290

DatePicker initially used java.util.Date, however it was felt 
that java.sql.Date better represents a real date.

Internally however java.sql.Date just makes a few depricated 
method calls illegal and provides some parsing methods. It 
still stores its value in milliseconds. So java.sql.Date 
comparisons can still be different on the same date.  Sun's 
design of the date stuff is pretty poor.

In summary I dont have a problem changing this back to 
java.util.Date, though there may be some impact existing 2.2 
applications

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354754&aid=648435&group_id=4754


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf