我应该使用java.util.Date还是切换到java.time.LocalDate

时间：2015-02-25 21:37:23

标签： java date jdbc

编辑：嗯，显然这是基于意见的，所以让我试着更准确地改写它 -

在不需要任何向后兼容性的Java代码中使用LocalDate，LocalTime等是否有任何明确的警告或缺点，如果是这样 - 它们是什么？

我正在寻找诸如“当前EE库X和Y无法正确使用LocalDate”或“这个非常有用的模式被LocalTime打破”等等。

（这是原始问题供参考）

使用Java 8，引入了新的时间API，即java.time.LocalDate等，但java.util.Date未标记为已弃用。

我正在编写一个新项目，它不需要向后兼容。我应该只使用LocalDate，LocalDateTime等吗？使用这个新API是否有任何缺点，而不是旧的java.util.Date？

特别是 - 我将主要使用JDBC。从我所看到的JDBC很好地处理java.util.Date。它是否适合LocalDate？

搜索产生了很多网站，告诉他们如何从一种格式转换为另一种格式，但是如果新代码使用旧的API，则没有明确的答案。

感谢。

3 个答案:

答案 0 :(得分：34)

尽管有名称，但java.util.Date可用于存储日期和时间（它存储自纪元以来的UTC毫秒偏移量）

由于功能更强，我肯定会使用新的API：

  • 更容易格式化/解析。 API有自己的格式/解析方法
  • API包括加/减操作（minusMinutes，plusDays等）

以上都不适用于java.util.Date

Old Date也可以像这样转换为LocalDateTime：

Date oldDate = ...
LocalDateTime newDateTime = 
  LocalDateTime.from(Instant.ofEpochMilli(oldDate.getTime()));

答案 1 :(得分：2)

我要添加到correct Answer by Ole V.V.

JDBC 4.2

  

特别是-我将主要使用JDBC。

JDBC 4.2添加了对与数据库交换 java.time 对象的支持。请参见PreparedStatement::setObject和ResultSet::getObject方法。

ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
LocalDate today = LocalDate.now( z ) ;
myPreparedStatement.setObject( … , today ) ;

检索。

LocalDate ld = myResultSet.getObject( … , LocalDate.class ) ;

出于某些原因，JDBC规范 not 不需要支持两个最常用的类：Instant和ZonedDateTime。您的数据库和JDBC driver可能会也可能不会添加对它们的支持。

如果没有，您可以轻松转换。从OffsetDateTime开始，在JDBC中需要支持。

OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;

要查看特定地区（时区）人们使用的挂钟时间的这一刻，请应用ZoneId以获得ZonedDateTime对象。

ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = odt.atZoneSameInstant() ;

要调整为UTC，请提取Instant。根据定义，Instant始终采用UTC。

Instant instant = odt.toInstant() ;

您可以通过另一种方式转换为写入数据库。

myPreparedStatement.setObject( … , zdt.toOffsetDateTime() ;  // Converting from `ZonedDateTime` to `OffsetDateTime`. Same moment, same point on the timeline, different wall-clock time.

…并且：

myPreparedStatement.setObject( … , instant.atOffset( ZoneOffset.UTC ) ) ;  // Converting from `Instant` to `OffsetDateTime`. Same moment, same point on the timeline, and even the same offset. `OffsetDateTime` is a more flexible class with abilities such as (a) applying various offsets and (b) flexible formatting when generating text, while `Instant` is meant to be a more basic building-block class.

请注意naming convention used in java.time：at，from，to，with等。

Table of date-time types in Java (both modern and legacy) and in standard SQL.

关于 java.time

java.time框架已内置在Java 8及更高版本中。这些类取代了麻烦的旧legacy日期时间类，例如java.util.Date，Calendar和SimpleDateFormat。

要了解更多信息，请参见Oracle Tutorial。并在Stack Overflow中搜索许多示例和说明。规格为JSR 310。

目前位于Joda-Time的maintenance mode项目建议迁移到java.time类。

您可以直接与数据库交换 java.time 对象。使用符合JDBC driver或更高版本的JDBC 4.2。不需要字符串，不需要java.sql.*类。

在哪里获取java.time类？

ThreeTen-Extra项目使用其他类扩展了java.time。该项目为将来可能在java.time中添加内容提供了一个试验场。您可能会在这里找到一些有用的类，例如Interval，YearWeek，YearQuarter和more。

答案 2 :(得分：1)

Java 8和更高版本：不用担心

不，如果您使用的是Java 8或更高版本（内置Java），则没有理由不希望使用现代的Java日期和时间API java.time。

您可能要简要考虑的唯一一件事就是您已经排除的那件事。

  

我正在编写一个新项目，该项目不需要向后兼容。

即使是向后兼容，您也可以安全地使用java.time，因为转换方法是Java 8的旧类内置的。

Java 6和7：称重

如果您使用的是Java 6或7，则需要为Java.time使用ThreeTen-Backport，对于ThreeTenABP中API级别26以下的Android进一步适用。如果您只进行很少的非常简单的日期和时间工作，并且以某种方式不存在向前兼容性，则可以考虑是否值得使用外部依赖关系。请注意，您的外部依赖关系只是Java 8及更高版本内置的反向支持，因此非常可靠，因此，在迁移到Java 8或更高版本之前，只需要它即可。那时您可以更改导入，重新测试并取消向后移植。

您的实际负债示例

  

当前EE库X和Y在LocalDate上无法正常工作

有一些例子，还有JDK中的库类。我的选择是在自己的代码中使用java.time，并且仅在调用尚未接受java.time类型的API之前进行转换。相反，如果我从API获取了一个过时的类的实例，请先将其转换，然后使用java.time进行其余操作。

  

这个非常有用的模式被LocalTime破坏了

我知道没有这种模式。相反，与大多数旧类相反，java.time使用模式不可变对象和工厂方法。

相关问题
最新问题