java - JSR 310::System.currentTimeMillis() 与 Instant.toEpochMilli()::TimeZone

Question

您能否阐明如何为默认系统时区和给定时区获取以毫秒为单位的正确纪元时间。

给定

1.时区:GMT+3

2。以下代码片段:

import java.time.*;

public class Main {        
    public static void main(String[] args) {
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.UTC)
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.of("+3"))
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(System.currentTimeMillis());
    }
}

3。输出:

1444158955508
1444148155508
1444148155508

4. System.currentTimeMillis() 的 JavaDoc表明返回值将是当前时间与 1970 年 1 月 1 日午夜 UTC 之间的差值，以毫秒为单位。

那么，为什么

1. LocalDateTime 在 GMT+3 的输出与 System.currentTimeMillis() 相同，尽管 的文档code>System.currentTimeMillis() 提到 UTC?
2. LocalDateTime 在 UTC 的输出不同于 System.currentTimeMillis()，尽管 System.currentTimeMillis 的文档() 提到 UTC?

Answer 1

System.currentTimeMillis() 和 Instant.toEpochMilli() 都返回自 Unix 纪元以来的毫秒数。这不是“在”任何特定时区，尽管 Unix 纪元通常表示为“1970 年 1 月 1 日午夜，UTC”。但瞬间只是时间上的瞬间，无论您身处哪个时区，它都是一样的 - 但它会反射(reflect)不同的本地时间。

LocalDateTime.atZone(UTC) 的输出不同，因为您说的是“采用本地日期和时间，并将其转换为即时，就好像它是 UTC 时间一样zone” - 即使当您创建 LocalDateTime 时，您在 UTC+3 时区中隐含地这样做了……这就是为什么它是“错误的”。

LocalDateTime.now() 采用系统默认时区中的本地日期和时间。所以如果你的时区是UTC+3，当前时间是2015-10-06T16:57:00Z，那么LocalDateTime.now()会返回.2015-10-06T19 :57:00。我们称它为 localNow...

所以 localNow.atZone(ZoneOffset.of("+3")) 将返回一个 ZonedDateTime 代表 2015-10-06T19:57:00+03 - 在换句话说，相同的本地日期/时间，但“知道”它比 UTC 早 3 小时...所以 toInstant() 将返回代表 2015-10 的 Instant -06T16:57:00Z。太好了 - 我们还有当前的日期/时间。

但是 localNow.atZone(ZoneOffset.UTC) 将返回代表 2015-10-06T19:57:00Z 的 ZonedDateTime - 换句话说，相同的本地日期/时间，但“认为”它已经在 UTC 中了……所以 toInstant() 将返回代表 2015-10-06T19:57:00Z 的 Instant.. 这是根本不是当前时间(三小时后)。