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

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

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

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

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

获得相同的值

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

Answer 1

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

假设你花了10分钟在你所在的时区写这个问题，那么在我所在的时区里它将是10分钟。

Answer 2

我有已建立时区systemDefault
的LocalDateTime

不，你没有。您开始使用LocalDateTime，但之后又将其转换为ZonedDateTime。 ZonedDateTime实际上是LocalDateTime ZoneId，与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)和((ToDoActivity)Activity).LoginUserFacebook();之间的差异 - 后者将始终“正确”知道偏移量。

java中的日期，偏移和时区

2 个答案: