我正在尝试修改现有的java代码，以毫秒而不是秒为单位输出数据。
返回当前时间（GMT秒）的现有代码：
currentTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);
输出当前时间=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在milisec能够获得当前系统时间在milisec，但是我如何偏移结果GMT时间。
currentTime = ZonedDateTime.now().toInstant().toEpochMilli();
输出当前时间=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-argnow使用JVM的默认时区，这是不可靠的，因为设置可能会意外更改，并且可能会导致混淆。如果在上面的代码行中说明了时区，我们都可以一目了然地看到它是否与之后假设的UTC一致。Instant.now（）是个例外：它不需要时区，因为它在所有时区都给出相同的结果。
您在我的计算机上的旧代码在欧洲/哥本哈根时区的输出是：
1566376327
您可以看到它与我们之前得到的毫秒值不一致（在这种情况下提前了两个小时；在你的情况下，它落后了7个小时）。
你的问题似乎是在10PM（22:00）GMT（3PM偏移-07:00）左右发布的，所以你的结果都不适合那个时间。要么是从运行代码到发布问题花了几个小时；要么你的计算机时钟设置不正确。
