以毫秒为单位将当前系统时间偏移到时区 GMT

Question

我试图修改现有的 java 代码以毫秒而不是秒为单位输出数据。

以秒为单位返回格林威治标准时间当前时间的现有代码：

currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);

输出currentTime = 1566311076

它说使用纪元转换器

GMT: Tuesday, August 20, 2019 2:24:36 PM

Your time zone: Tuesday, August 20, 2019 7:24:36 AM GMT-07:00 DST

我尝试修改 java 代码以返回以毫秒为单位的 GMT 中的当前时间能够以毫秒为单位获取当前系统时间，但是如何将结果偏移到 GMT 时间。

currentTime = ZonedDateTime.now().toInstant().toEpochMilli();

输出currentTime = 1566336256566

假设这个时间戳是毫秒

GMT: Tuesday, August 20, 2019 9:24:16.566 PM

Your time zone: Tuesday, August 20, 2019 2:24:16.566 PM GMT-07:00 DST

你知道吗，会非常感激的。谢谢！

Answer 1

转换为Instant第一个：currentTime = LocalDateTime.now().toInstant(ZoneOffset.UTC).toEpochMilli()演示System.out.println(LocalDateTime.now().toEpochSecond(ZoneOffset.UTC));System.out.println(LocalDateTime.now().toInstant(ZoneOffset.UTC).toEpochMilli());输出15663237731566323773363

Answer 2

当存在简单的方法时，为什么要以更复杂的方式进行呢？    long currentTime;     currentTime = System.currentTimeMillis();     System.out.println(currentTime);刚才的示例输出：1566369127348我强烈支持使用现代 java.time 类，包括ZonedDateTime（可能不多LocalDateTime）。然而，在这种情况下，Java 诞生时的一个简单方法给了我们想要的东西。我认为使用它没有问题。如果您确实想使用 java.time，请使用Instant：    currentTime = Instant.now().toEpochMilli();     System.out.println(currentTime);1566369127348你的代码出了什么问题？奇怪的是你的旧代码不正确。您的新尝试给出了自纪元以来的正确毫秒数。您的旧代码是：    currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);这将采用您所在时区的当前挂钟时间，或者更准确地说，采用 JVM 的默认时区。然后它错误地假设时间是 UTC，并根据这个假设将它转换为自纪元以来的秒数（当然，如果 JVM 的时区是 UTC，你会碰巧得到正确的结果）。我建议您始终将时区（如果不是时钟）传递给一种now方法，以使您对所用时区的期望明确。no-argnow使用 JVM 的默认时区，这是不可靠的，因为设置可能会意外更改，并可能导致混淆。如果在上面的代码行中写明了时区，我们一眼就能看出它是否符合后面假设的UTC。例外是 Instant.now()：它不需要时区，因为它在所有时区都给出相同的结果。我在欧洲/哥本哈根时区的计算机上旧代码的输出是：1566376327您可以看到它与我们之前获得的毫秒值不一致（在本例中它提前了两个小时；在您的情况下它落后了 7 小时）。您的问题似乎已在格林威治标准时间晚上 10 点（22:00）左右（偏移量 -07:00 下午 3 点）发布，因此您的结果都不符合那个时间。从运行您的代码到发布您的问题已经过去了几个小时；或者您的计算机时钟设置不正确。