java.util.Date vs java.sql.Date

java.util.Date vs java.sql.Date: when to use which and why?

基本上，数据库通常支持至少三种形式的日期时间字段，即日期，时间和时间戳。它们中的每一个在JDBC中都有一个对应的类，每个类都扩展了java.util.Date。这三者中的每一个的快速语义如下：

java.sql.Date对应于SQL DATE，这意味着它存储了年，月和日，而忽略了小时，分钟，秒和毫秒。另外，sql.Date与时区无关。
java.sql.Time对应于SQL TIME，应该很明显，只包含有关小时，分钟，秒和毫秒的信息。
java.sql.Timestamp对应于SQL TIMESTAMP，它是纳秒的精确日期（请注意，util.Date只支持毫秒！），具有可自定义的精度。
使用与这三种类型相关的JDBC驱动程序时最常见的错误之一是类型处理不正确。这意味着sql.Date是特定于时区的，sql.Time包含当前年，月和日等等。

最后：哪一个使用？
真的，取决于该字段的SQL类型。 PreparedStatement具有所有三个值的setter，＃setDate（）为sql.Date，＃setTime（）为sql.Time，＃setTimestamp（）为sql.Timestamp。

请注意，如果使用ps.setObject（fieldIndex，utilDateObject）;你实际上可以给大多数JDBC驱动程序提供一个普通的util.Date，它会愉快地吞噬它，就好像它是正确的类型但是当你之后请求数据时，你可能会注意到你实际上缺少了东西。

从Java 8开始，你应该既不使用java.util.Date也不使用java.sql.Date，如果你可以完全避免它，而是更喜欢使用java.time包（基于Joda）而不是其他任何东西。如果您不使用Java 8，这是原始响应：

java.sql.Date - 当您调用使用它的库的方法/构造函数（如JDBC）时。不是这样。您不希望为未明确处理JDBC的应用程序/模块引入数据库库的依赖项。

java.util.Date - 使用使用它的库时。否则，尽可能少，原因有以下几点：

它是可变的，这意味着每次将它传递给方法或从方法返回时，你必须制作它的防御性副本。

它不能很好地处理日期，真正的倒退人们认为日期处理类应该。

现在，因为java.util.Date不能很好地完成它的工作，所以引入了可怕的日历类。它们也是可变的，并且可以使用，如果你没有任何选择，应该避免使用它们。

还有更好的选择，比如Joda Time API（它甚至可以进入Java 7并成为新的官方日期处理API - 快速搜索说它不会）。

如果你认为引入一个像Joda这样的新依赖项是不合适的，那么longs对于对象中的时间戳字段来说并不是那么糟糕，尽管我自己通常在传递它们时将它们包装在j.u.D中，用于类型安全和文档。

翻译：https://stackoverflow.com/questions/2305973/java-util-date-vs-java-sql-date