java - 使用 TimeZone 的 Calendar.getInstance 与 new Date()

Question

我在我的应用程序中编写了一个实用程序，它接受时区并返回一个日期(java.util.Date)，如下 -

// Inside MyDateHelper.java
public static java.util.Date getTimeForTimeZone(String timeZoneId)
{
    final Date currentDate = Calendar.getInstance(TimeZone.getTimeZone(timeZoneId)).getTime();
    return currentDate;
}

我在互联网上进行了研究，发现 Date 中没有任何时区信息。相反，它是一个从 1970 年开始的长值的包装器。所以，我的问题是我是否必须获取当前发生事务的日期时间时刻以存储在日期字段(类型为 java.util.Date)中)，这个实用程序有什么用吗？

出于所有实际目的，这两行代码实现的效果是相同的吗？

transactionEntry.setTime(MyDateHelper.getTimeForTimeZone("UTC+7:00"));

或者

transactionEntry.setTime(new Date());

我还检查了新的 Java 8 Time API，但就我的目的而言，我认为这样做也是一种矫枉过正，并且没有实现更多 new Date() -

Date date4 = new Date();
LocalDateTime localDate = date4.toInstant().atZone(ZoneId.of("UTC+07:00")).toLocalDateTime();
final ZonedDateTime dateWithZone = localDate.atZone(ZoneId.of("UTC+07:00"));
Date dateOutput = Date.from(dateWithZone.toInstant());
transactionEntry.setTime(dateOutput);

整个目的是捕获时区事务发生的时间，但我只能将时间存储为 java.util.Date。无论交易发生在哪个时区，Date 都能够正确捕获时间的瞬间，对吗？有人可以证实这种理解是正确的吗？

Answer 1

Answer by Ole V.V.是正确的。我将添加一些讨论。

地球上的每个人同时经历的时间线只有一条(忽略爱因斯坦等人)。按照惯例，我们使用 UTC 来追踪该时间。

学会将 UTC 视为唯一的真实时间。所有其他偏移量和区域都只是 UTC 的变体。当担任程序员或系统管理员时，请忘记您自己的狭隘时区。再次单击桌面或墙上的 UTC 跟踪时间。在 UTC 中进行所有日志记录、跟踪、数据存储和数据交换。

用于跟踪 UTC 时刻的基本类是 java.time.Instant。根据定义，此类的对象始终采用 UTC。该类取代了 java.util.Date，它也代表 UTC 中的某个时刻，但有许多设计缺陷，永远不应该使用。 Instant 的分辨率为纳秒，比 Date 的毫秒更精细。

为了获得更大的灵 active ，请使用 OffsetDateTime 类。

OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;

然后又回来了。

Instant instant = odt.toInstant() ;

相对于 UTC 的偏移量只是小时、分钟、秒的数量。时区的意义要大得多。时区是特定地区的人们使用的偏移量的过去、现在和 future 变化的历史。

要使用时区，请应用 ZoneId 来获取 ZonedDateTime。这个类取代了可怕的 Calendar 和 GregorianCalendar 类。

ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = instant.atZoneId( z ) ;

又回来了。

Instant instant = zdt.toInstant() ;

这个zdt、odt和instant都代表同一时刻，同一点时间线。

最后，停止使用日期和日历。 Sun、Oracle 和 JCP 社区在采用 JSR 310 时都放弃了这些类，您也应该如此。那些遗留类确实是一团糟。