基于UTC而不是本地时间创建JSR 310时钟？

Question

编辑：好的。不幸的是，我不得不承认我对Java时间的理解存在严重缺陷，使得这个问题毫无意义。我一直认为System.currentTimeMillis（）返回了当地时间。为什么？因为当你用它创建一个Date时，它只包含那个，没有引用时区，但在传递给System.out.println（）时仍然打印出当地时间。我从未想过是toString（）将（UTC）时间转换为当地时区。：（

我想用Java创建一个客户机-服务器应用程序。时间起着重要作用。因此，我决定暂时采用GMT/UTC标准。我还从经验中了解到，许多用户的PC具有完全错误的时间和/或时区。最后，我想得到比毫秒更精确的时间。

所以我创建了一个类，它在开始时连接到Internet，并计算到UTC的偏移量，独立于本地时间和时区。换句话说，我有一个静态Java方法，它以纳秒为单位返回UTC时间，并且独立于本地时间设置在任何PC上工作。

现在，我的问题是我想使用JSR 310来操作时间（实际上是Java7反向端口），我看不到如何定义一个不基于本地时间的时钟。

在我看来，这些方法似乎是时钟。米利斯（）和时钟。instant（）必须使用本地时间才能正常工作[编辑：因为这些方法盲目返回System.currentTimeMillis（），与设置的时区属性无关]。因此，我基本上必须将UTC时间转换为本地时间，以创建一个瞬间，这样我就可以创建一个UTC ZonedDateTime，将本地时间再次转换为UTC时间。这太疯狂了。如果我在时钟中使用UTC时间。米利斯（）和时钟。instant（），然后创建一个UTC ZonedDateTime，本地时间偏移量（我不想与之有任何关系）将应用两次。

从UTC转换到本地再转换回来的成本很高，因此我非常希望能够使用纯UTC。我正在开发一款实时游戏，而不是一款网络应用程序，在那里，如此小的延迟将毫无意义。

我可以返回UTC时间，然后“假装”时区是“本地”的，以获得正确的数字，但事情可能会在DST边界处发生变化，这会使将时间转换为其他时区变得更加复杂。

这是我的时钟班

Answer 1

解决方案是：您可以更改时区：

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

因此，要在时钟中使用UTC，但仍然能够在本地用户时区显示时间值，您必须首先获取并保存默认的TimeZone，然后如上所述仅将其替换为UTC。

然后，JVM会认为您的本地时区是UTC，因此，如果时钟实际返回UTC毫秒和instant，那么一切都将协同工作。然后，当您想要显示时间值时，您将获得原始的默认时区，并使用该时区创建另一个时钟实例，但millis和instant方法保持不变，因此它们仍然返回UTC时间。

主要的好处是，现在任何地方都不需要时区转换，除非在本地时间向用户显示。

[再想一想，这一点的价值有限，因为其他一切都将使用System.currentTimeMillis（）（包括通过java.util.Date和Calendar间接进行编辑）。因此，可能永远无法解决所有与时间相关的问题。]

Answer 2

在我看来，这些方法似乎是时钟。米利斯（）和时钟。instant（）必须使用当地时间才能正常工作。

绝对不行。Instant与时区无关，millis记录为：

这将返回基于毫秒的瞬间，从1970-01-01T00:00 UTC开始测量。这相当于系统的定义。currentTimeMillis（）。

所以再说一遍，现在不是当地时间。它使用本地系统时钟，但这与说它是正常意义上的本地时间不同。

现在还不清楚您真正想做什么，但我至少会尝试在即时方面做每件事，而不是分区最新时间。瞬间的意义在于它只是时间线上的一个点；它没有时区，甚至没有日历系统。只要您使用的所有东西（在所有系统中）都使用相同的概念时间线和相同的历元（例如，如果您在任何地方都使用JSR-310），那么您就可以了<代码>即时（code>Instant）使用与Java相同的纪元—1970年UTC开始。

当然，您可能仍然希望有自己的时间来源，但显然您需要考虑网络延迟等。考虑使用标准化NTP或类似的东西，而不是尝试构建自己的系统。然后，您可能希望对其进行调整，以自己实现时钟的子类。如果其他一切都只是在时钟方面工作，那么您的代码将很好并且可以测试，而不涉及网络服务。