Dav*_*ley 3 java server-side application-server
我已经实现了一个服务器端应用程序,它记录了创建和更新记录时的时间戳.该应用程序假定服务器时钟没有启用夏令时,(a)因为我读过这是最佳做法和(b)因为我认为处理发生的歧义会很棘手(如果不是不可能的话),例如,当时钟在10月回归一个小时.
为安全起见,如果应用程序在启动时检测到DST已启用,则会记录错误并终止应用程序.即使应用服务器时钟启用了DST,我也会被内部利益相关者请求使应用程序正常工作.
我觉得尝试这样做是个愚蠢的事情,但我需要说服管理层.只是因为它使实现变得更加棘手,或者它是否存在根本上的缺陷,以至于这样的应用程序(记录时间戳)在一年中的任何时候都无法正确运行100%？在没有启用DST的情况下运行这样的应用程序的最佳理由是什么？
我想出的最好的是:
启用夏令时后,每年有两次不连续时间.请考虑以下情形,其中服务器在英国运行,时钟设置为启用夏令时的本地时间:2009年10月25日凌晨2点,时钟可以追溯到凌晨1点到凌晨1点. 记录在凌晨1点30分创建 应用程序(必须以UTC格式存储时间戳)无法判断这是在时钟返回之前或之后的1.30am,因此无法确定是否在UTC调整中包含额外的小时.
这是真的？实际上是否可以确定(在Java Web应用程序中)10月25日凌晨1点30分发生的事件是在时钟调整之前还是之后？
避免夏令时的任何更好的理由？
更新
需要明确的是,应用程序必须将时间存储为UTC.问题是为什么在尝试这样做时,在服务器计算机上启用DST是一个坏主意.
pax*_*blo 14
我发现(从多年的糟糕经历中)最好将日期和时间存储为UTC,并且只在用户想要查看它们时将它们转换为本地时间.
此外,让用户输入本地时间,但在存储之前将其转换为UTC.
这将为您节省各种问题,包括尝试弄清楚当您的应用程序分布在多个时区时会发生什么.
如果您只获得并存储UTC时间,那么DST无关紧要.
我们继承的一个特别讨厌的应用程序发送了带有时区的本地时间消息,需要花费大量精力来经常修改这些消息.
当我们将其修改为仅使用UTC时,它会好得多.一端尽可能早地转换为UTC,转换到当地时间推迟到最后一刻.代码变得更小,速度更快.