java中的日期、偏移量和时区

Question

我正在努力理解时态实用程序的底层机制。

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

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

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

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

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

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

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

Answer 1

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

假设你在你的时区花了10分钟写这个问题，在我的时区也会花10分钟。

Answer 2

我有已建立时区系统的LocalDateTime默认

不，你没有。您从LocalDateTime开始，但后来将其转换为ZonedDateTime。CCD_ 10实际上是具有CCD_ 12和距UTC的偏移量的CCD_。

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

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

请注意，您的代码可能会给您一个不同的结果-如果您所在的时间段由于时钟倒退而导致LocalDateTime.now()不明确（通常是在夏令时结束时）。在这种情况下，LocalDateTime.atZone会选择LocalDateTime的较早出现，而在现实中，您可能会经历较晚的出现。这就是LocalDateTime.now().atZone(zone)和ZonedDateTime.now(zone)之间的区别——后者总是能正确地"知道"偏移量。