3

我已经实现了一个服务器端应用程序，它在创建和更新记录时记录时间戳。该应用程序假定服务器时钟没有启用夏令时，（a）因为我已经阅读了这是最佳实践，（b）因为我认为处理发生的歧义会很棘手（如果不是不可能的话），例如，10 月时钟倒退一个小时。

为安全起见，如果应用程序在启动时检测到 DST 已启用，则会记录错误并终止应用程序。即使应用服务器时钟启用了 DST，内部利益相关者也请求我使应用程序正常工作。

我觉得这是一件很鲁莽的事情，但我需要说服管理层。仅仅是它使实施变得更加棘手，还是存在根本缺陷，以至于这样的应用程序（记录时间戳）不可能在一年中的任何时候都 100% 正确运行？在启用 DST 的情况下不运行此类应用程序的最佳论据是什么？

我想出的最好的是：

启用夏令时时，每年有两次时间不连续。考虑以下场景，其中服务器在英国运行，时钟设置为本地时间并启用了夏令时：
  • 2009 年 10 月 25 日凌晨 2 点，时钟倒退一小时到凌晨 1 点。
  • 1.30am 创建记录
  • 该应用程序（必须以 UTC 存储时间戳）无法判断这是时钟倒退之前还是之后的凌晨 1.30，因此无法确定是否在调整 UTC 时包括额外的一小时。

    • 这是真的？实际上是否可以确定（在 Java 网络应用程序中）在 10 月 25 日凌晨 1.30 发生的事件是在时钟调整之前还是之后？

    避免 DST 的更好理由是什么？

    更新

    需要明确的是，应用程序必须将时间存储为 UTC。问题是为什么在尝试这样做时，在服务器机器上启用 DST 是个坏主意。

    4

    3 回答 3

    14

    我发现（从多年的不良经验中）最好将日期和时间存储为 UTC，并且仅在用户想要查看它们时将它们转换为本地时间。

    此外，让用户输入当地时间，但在存储之前将其转换为 UTC。

    这将为您节省各种问题，包括试图弄清楚当您的应用程序分布在多个时区时发生了什么。

    如果您只获取和存储 UTC 时间，那么 DST 无关紧要。

    我们继承的一个特别讨厌的应用程序使用本地时间和跨时区的时区发送消息，需要花费大量精力来频繁修改这些消息。

    当我们将其修改为仅使用 UTC 时，它会好很多。尽可能早地转换为一端的 UTC，转换为本地时间被推迟到最后一个可能的时刻。代码变小了很多，速度也快了很多。

    于 2009-10-08T13:39:06.510 回答
    5

    没有理由在服务器上禁止 DST，因为时区（或者我应该说“应该”）只不过是格式化而已。系统时钟与时区无关。时间戳应该以明确的格式存储，或者作为“自纪元以来的滴答声”System.currentTimeMillis()及其同类（与时区无关），或者作为具有指定 UTC 偏移量的文本（然后变得明确，如ISO 8601）。

    于 2009-10-08T13:46:26.403 回答
    0

    只要您使用内置的 Java 类来存储日期和时间，DST 就不是问题。时间的内部表示是“1970 年 1 月 1 日午夜过后的毫秒数，在格林威治英格兰”，因此您所在的时区或 DST 是否生效是无关紧要的。

    永远不要尝试使用文本表示来比较两个日期或时间，例如“10/09/2009”或其他。使用长毫秒值。我现在正在开发一个系统，原始作者似乎每次想要比较两个日期时都使用不同的方法。在一个地方，他们将日期表示为 yyyy/mm/dd，然后去掉斜线，将结果转换为整数——因此 10/08/2009 变为 20,091,008——然后将它们相互比较。其他时候，他们将它们作为文本字符串进行比较。等等。当涉及多个时区或 DST 时，这会在整个地方产生不正确的结果。

    于 2009-10-08T14:00:57.950 回答