Re: BUG for date
Tobias Downer <[email protected]>
| Newsgroups | gmane.comp.db.mckoi |
|---|---|
| Message-ID | <[email protected]> |
Please don't be concerned with using the setDate and getDate methods. Just be aware of the timezone issue. My suggestion in the previous email was only to show a simple way to work around the timezone issue if the timezone on the client and server are not the same. Regarding java.util.Date performance, Mckoi primitively stores dates as a single 64-bit 'long' value. Mckoi will only wrap this value around a java.util.Date object if some operation is performed on the date. Toby. Christopher Brown wrote: > So it's best not to use PreparedStatement.setDate (or Timestamp) and the > corresponding "getters" in ResultSet ? > > Incidentally, Date has performance problems due to it being mutable > (everything passes through an internal synchronization bottleneck). The > "joda-time" project on sourceforge provides a credible alternative that > might be useful internally. > > Any news on an upcoming release with enhanced date support (timezones, date > functions, etc.)..? "1.0.3"'s been around a while now... > > - Chris --------------------------------------------------------------- Mckoi SQL Database mailing list http://www.mckoi.com/database/ To unsubscribe, send a message to [email protected]