It's mutable, which means you have to make a defensive copy of it every time you pass it to or return it from a method. Otherwise, as little as possible, for several reasons: You don't want to introduce dependencies to the database libraries for applications/modules that don't explicitly deal with JDBC. when you call methods/constructors of libraries that use it (like JDBC). If you're not on Java 8, here's the original response: LATE EDIT: Starting with Java 8 you should use neither nor if you can at all avoid it, and instead prefer using the java.time package (based on Joda) rather than anything else.
#Java.util.sql setdate portable#
These magic numbers can be used in SQL queries and will be portable from database to another and will let you avoid this part of JDBC/Java Date API:s entirely. One hacky way which can be done is to store the date component as one long and time component as another, for example right now would be 20100236123. What I am saying that save the milliseconds/nanoseconds as plain longs and convert them to whatever objects you are using ( obligatory joda-time plug). I'm really saying that none of the Dates should be used at all.
#Java.util.sql setdate drivers#
PreparedStatement has setters for all three values, #setDate() being the one for sql.Date, #setTime() for sql.Time and #setTimestamp() for sql.Timestamp.ĭo note that if you use ps.setObject(fieldIndex, utilDateObject) you can actually give a normal util.Date to most JDBC drivers which will happily devour it as if it was of the correct type but when you request the data afterwards, you may notice that you're actually missing stuff.
Finally: Which one to use?ĭepends on the SQL type of the field, really. This means that sql.Date is timezone specific, sql.Time contains current year, month and day et cetera et cetera. One of the most common bugs when using JDBC drivers in relation to these three types is that the types are handled incorrectly. corresponds to SQL TIMESTAMP which is exact date to the nanosecond ( note that util.Date only supports milliseconds!) with customizable precision.corresponds to SQL TIME and as should be obvious, only contains information about hour, minutes, seconds and milliseconds.Additionally sql.Date isn't tied to timezones. corresponds to SQL DATE which means it stores years, months and days while hour, minute, second and millisecond are ignored.Quick semantics of each of these three are the following: Each of these have a corresponding class in JDBC and each of them extend. Congratulations, you've hit my favorite pet peeve with JDBC: Date class handling.īasically databases usually support at least three forms of datetime fields which are date, time and timestamp.
0 kommentar(er)
