以毫秒为单位将当前系统时间偏移到时区 GMT
offset current system time to time zone GMT in millisecs
我正在尝试修改现有的 java 代码以以毫秒而不是秒为单位输出数据。
现有代码return GMT 当前时间（以秒为单位）：
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 代码修改为 return 当前时间（以毫秒为单位的格林威治标准时间）能够获得以毫秒为单位的当前系统时间，但是如何将结果偏移到格林威治标准时间。
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
你知道吗，将不胜感激。谢谢！
首先转换为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());
输出
1566323773
1566323773363
既然有简单的方法，为什么要用更复杂的方法呢？
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-arg now 使用 JVM 的默认时区，这是不可靠的，因为设置可能会意外更改，并可能导致混乱。如果在上面的代码行中写明了时区，我们一眼就能看出它是否符合后来假设的UTC。例外是 Instant.now()：它不需要时区，因为它在所有时区给出相同的结果。
我计算机上 Europe/Copenhagen 时区的旧代码输出为：
1566376327
你可以看到它与我们之前得到的毫秒值不一致（在这种情况下它提前了两个小时；在你的情况下它落后了 7 小时）。
您的问题似乎是在格林威治标准时间晚上 10 点 (22:00) 左右（下午 3 点偏移量 -07:00）发布的，因此 none 您的结果与那个时间很吻合。从 运行 您的代码到发布您的问题已经过去了几个小时；或者你的电脑时钟设置不正确。
我正在尝试修改现有的 java 代码以以毫秒而不是秒为单位输出数据。
现有代码return GMT 当前时间（以秒为单位）：
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 代码修改为 return 当前时间（以毫秒为单位的格林威治标准时间）能够获得以毫秒为单位的当前系统时间，但是如何将结果偏移到格林威治标准时间。
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
你知道吗，将不胜感激。谢谢！
首先转换为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());
输出
1566323773
1566323773363
既然有简单的方法，为什么要用更复杂的方法呢？
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-arg now 使用 JVM 的默认时区，这是不可靠的，因为设置可能会意外更改，并可能导致混乱。如果在上面的代码行中写明了时区，我们一眼就能看出它是否符合后来假设的UTC。例外是 Instant.now()：它不需要时区，因为它在所有时区给出相同的结果。
我计算机上 Europe/Copenhagen 时区的旧代码输出为：
1566376327
你可以看到它与我们之前得到的毫秒值不一致（在这种情况下它提前了两个小时；在你的情况下它落后了 7 小时）。
您的问题似乎是在格林威治标准时间晚上 10 点 (22:00) 左右（下午 3 点偏移量 -07:00）发布的，因此 none 您的结果与那个时间很吻合。从 运行 您的代码到发布您的问题已经过去了几个小时；或者你的电脑时钟设置不正确。