代码之家 › 专栏 › 技术社区 › David Easley

为什么不运行启用夏令时的服务器端应用程序?

server-side application-server java

David Easley · 技术社区 · 15 年前

我实现了一个服务器端应用程序,它在创建和更新记录时记录时间戳。该应用程序假设服务器时钟没有启用夏令时,(a)因为我已经阅读了这是最佳实践,(b)因为我认为处理出现的含糊不清(如10月时钟返回一个小时)是很困难的(如果不是不可能的话)。

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

我觉得这是一件很鲁莽的事情,但我需要说服管理层。是因为它使实现变得更加复杂,还是因为它的根本缺陷使得这样一个应用程序(记录时间戳)在一年中的任何时候都无法100%正常运行?不运行启用DST的应用程序的最佳理由是什么?

我想到的最好办法是:

启用夏令时时,每年有两个时间中断。考虑以下场景,其中服务器在英国运行,时钟设置为本地时间,启用日光节约:
2009年10月25日凌晨2点,时钟回到凌晨1点。

在凌晨1:30创建记录

应用程序(必须以UTC格式存储时间戳)无法判断时钟返回之前或之后是凌晨1:30,因此无法确定是否在调整到UTC时包含额外的小时。

这是真的吗?实际上,是否可以确定(在Java Web应用程序中)10月25日上午1点30分发生的事件是在时钟调整之前还是之后?

有没有更好的理由避免DST?

更新

只是说清楚,这是一个给定的应用程序必须商店作为UTC时代。问题是,为什么在尝试这样做时,在服务器机器上启用DST是一个坏主意。

3 回复 | 直到 15 年前

gustafc 15 年前

没有理由在服务器上禁止DST,因为时区(或者我应该说“应该”)只不过是格式化而已。系统时钟与时区无关。时间戳应以明确的格式存储,可以是“从epoch开始的刻度”,例如 System.currentTimeMillis() 其ILK(不区分时区)或指定了UTC偏移量的文本(然后变得明确,如 ISO 8601 )

paxdiablo 15 年前

我发现(从多年的糟糕经历中)最好将日期和时间存储为UTC,并且仅在用户希望查看时将其转换为本地时间。

另外,让用户输入本地时间,但在存储之前将其转换为UTC。

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

如果您只获取和存储UTC时间,那么DST就不重要了。

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

当我们将它修改为只使用UTC时,它要好得多。在一端转换到UTC的时间越早越好,转换到本地时间的时间推迟到最后一个可能的瞬间。代码变得更小、更快。

Jay 15 年前

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

千万不要试图用文本表示来比较两个日期或时间,比如“2009年9月10日”之类的。使用长毫秒值。我现在正在研究一个系统,在这个系统中,最初的作者每次想要比较两个日期时似乎都使用不同的方法。在一个地方,他们将日期表示为YYYY/MM/DD,然后去掉斜杠,将结果转换为整数,所以10/08/2009变为20091008,然后将它们相互比较。其他时候,他们将它们作为文本字符串进行比较。等。当涉及多个时区或DST时,这会在各地产生不正确的结果。