java中的日期，偏移量和时区答案

【问题标题】：Datest, offsets and timezones in javajava中的日期，偏移量和时区
【发布时间】：2016-04-14 17:01:16
【问题描述】：

我试图了解时间效用的基本机制。

所以，我做了下一个例子：

public class Test {
    public static void main(String[] args) {

        System.out.println(Instant.now().getEpochSecond());
        System.out.println(new Date().getTime());
        System.out.println(LocalDateTime.now().atZone(ZoneId.systemDefault()).toEpochSecond());
        System.out.println(LocalDateTime.now().toEpochSecond(ZoneOffset.UTC));

        System.out.println(ZoneId.systemDefault().toString());
    }
}

输出是：

1460651620
1460651620182
1460651620
1460662420
Europe/Helsinki

我当前的系统默认 zoneId 是欧洲/赫尔辛基（+3 小时）
当我们创建 new Date() 时，它具有 unix 时间戳 (UTC)。

这是我比较打印结果的基点。

1.在我的第三个System.out 中，我有已建立时区systemDefault 的LocalDateTime，但输出实际上是相同的。我期望更大的价值（+3 小时）。

2. 在第四个输出行我虽然有令人困惑的结果。我期望与new Date().getTime() 具有相同的值

需要一些帮助来理解输出。

【问题讨论】：

标签： java timezone timezone-offset

【解决方案1】：

getEpochSecond() 和 toEpochSecond() 类型的任何方法都会为您提供自 1970-01-01T00:00:00Z 纪元以来的秒数，无论时区如何，时间运行方式相同，因此无论选择哪个时区，结果都是相同的。

假设你在你所在的时区花了 10 分钟来写这个问题，那么在我的时区也是一样的 10 分钟。

【讨论】：

【解决方案2】：

我有已建立时区 systemDefault 的 LocalDateTime

不，你没有。您从 LocalDateTime 开始，但随后将其转换为 ZonedDateTime。 ZonedDateTime 实际上是带有 ZoneId 的 LocalDateTime 和与 UTC 的偏移以处理歧义。

LocalDateTime 没有toEpochSecond() 方法，因为它不代表一个固定的时间点。它具有 toEpochSecond(ZoneOffset)，因为它通过应用 UTC 偏移量将本地日期/时间“锚定”到固定时间点。

比较一下ZonedDateTime 哪个确实有一个无参数的toEpochSecond() 方法，因为它代表一个固定的时间点，带有一个时区的附加上下文。（您可以将ZonedDateTime 视为Instant 与ZoneId，或将LocalDateTime 与ZoneId 和ZoneOffset 一起查看；它们是等价的，但我个人更喜欢后一种概念。）

请注意，您的代码可能会为您提供不同的结果 - 如果您处于 LocalDateTime.now() 由于时钟倒退（通常在夏令时结束时）而模棱两可的时期。在这种情况下，LocalDateTime.atZone 会选择较早出现的 LocalDateTime，而实际上您可能会遇到较晚出现的情况。这就是LocalDateTime.now().atZone(zone) 和ZonedDateTime.now(zone) 之间的区别——后者总是会正确“知道”偏移量。

【讨论】：