我希望将这个问题及其答案作为处理夏令时的最终指南,特别是处理实际转换时。

如果你有什么要补充的,请做

许多系统都依赖于保持准确的时间,问题是由于夏时制而导致的时间变化——向前或向后移动时钟。

例如,一个订单接受系统中的业务规则取决于订单的时间——如果时钟发生变化,规则可能就不那么清晰了。应如何保持订单的时间?当然,有无数的场景——这只是一个例证。

你是如何处理日光节约问题的?您的解决方案包含哪些假设?(在此处查找上下文)

同样重要,如果不是更重要的话:

你尝试了什么但没有奏效?为什么不起作用?

我会对编程、操作系统、数据持久性和其他相关方面感兴趣。

一般的答案很好,但我也希望看到细节,特别是如果它们只在一个平台上提供的话。


当前回答

您正在使用.NET框架吗?如果是这样的话,让我向您介绍一下与.NET3.5一起添加的DateTimeOffset类型。

此结构同时包含DateTime和Offset(TimeSpan),后者指定DateTimeOffset实例的日期和时间与协调世界时(UTC)之间的差异。

DateTimeOffset.Now静态方法将返回DateTimeOffset由当前(本地)时间和本地偏移组成的实例(如操作系统的区域信息中所定义)。DateTimeOffset.UtcNow静态方法将返回DateTimeOffset实例包含UTC中的当前时间(如如果你在格林威治)。

其他有用的类型是TimeZone和TimeZoneInfo类。

其他回答

商业规则应始终适用于民事诉讼时间(除非法律另有规定)。请注意,公民时间是一团糟,但这是人们使用的时间,所以这才是最重要的。

在内部,将时间戳保持在从大纪元开始的民用时间秒中。纪元并不特别重要(我喜欢Unix纪元),但它确实比其他纪元更容易。假装闰秒不存在,除非你正在做一些真正需要它们的事情(例如,卫星跟踪)。时间戳和显示时间之间的映射是应用DST规则的唯一点;规则经常变化(在全球范围内,一年几次;指责政客),所以你应该确保你没有硬编码地图。奥尔森的TZ数据库是无价的。

对于PHP:

PHP>5.2中的DateTimeZone类已经基于其他人提到的Olson DB,因此,如果您在PHP中而不是在DB中进行时区转换,则不必使用(难以理解的)Olson文件。

然而,PHP的更新频率不如Olson DB,因此仅使用PHPs时区转换可能会给您留下过时的DST信息,并影响数据的正确性。虽然这种情况预计不会经常发生,但如果您在全球拥有大量用户,这种情况可能会发生。

要解决上述问题,请使用timezonedb pecl包。它的功能是更新PHP的时区数据。根据更新的频率安装此软件包。(我不确定这个软件包的更新是否完全遵循奥尔森的更新,但它的更新频率似乎至少非常接近奥尔森更新的频率。)

我在两种类型的系统上找到了这一点,“轮班计划系统(例如工厂工人)”和“依赖天然气的管理系统”…

23小时和25小时的工作日是一个很难应付的问题,8小时的轮班需要7小时或9小时。问题是,你会发现每个客户,甚至客户的部门都有他们在这些特殊情况下创建的不同规则(通常没有记录)。

有些问题最好不要问客户,直到他们为您的“现成”软件支付了费用。很少有客户在购买软件时会提前考虑这类问题。

我认为在任何情况下,您都应该使用UTC记录时间,并在存储日期/时间之前转换为当地时间。然而,即使知道一个给定的时间是在哪,也很难使用夏令时和时区。

如果您的设计能够适应,请避免同时转换本地时间!

我知道对一些人来说,这可能听起来很疯狂,但想想用户体验:用户处理接近的相对日期(今天、昨天、下周一)比绝对日期(2010.09.17,星期五-9月17日)的速度要快。当你仔细考虑时,时区(和DST)的准确度越接近现在()就越重要,所以如果你可以用+/-1或2周的相对格式表示日期/日期时间,其余的日期可以是UTC,这对95%的用户来说并不重要。

通过这种方式,您可以以UTC存储所有日期,并以UTC进行相对比较,只需向用户显示超出相对日期阈值的UTC日期。

这也适用于用户输入(但通常以更有限的方式)。从只有{昨天、今天、明天、下周一、下周四}的下拉列表中进行选择,对于用户来说,比日期选择器更简单、更容易。日期选择器是表单填充中最令人痛苦的部分。当然,这并不适用于所有情况,但您可以看到,它只需要一点巧妙的设计就可以使其非常强大。

对于网络来说,规则没有那么复杂。。。

服务器端,使用UTC客户端,使用Olson原因:UTC偏移量不是夏令时安全的(例如,纽约是一年中的EST(UTC-5小时)部分,EDT(UTC-4小时)部分)。对于客户端时区确定,您有两个选项:1) 用户设置区域(更安全)资源:Web就绪的Olson-tz HTML下拉列表和JSON2) 自动检测区域资源:jsTimezoneDetect

剩下的只是使用服务器端日期时间库进行UTC/本地转换。很好去。。。