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

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

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

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

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

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

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

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

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


当前回答

实际上,kernel32.dll不导出SystemTimeToTzSpecificLocation。但是,它确实导出以下两个:SystemTimeToTzSpecificLocalTime和TzSpecificLocalTimeToSystemTime。。。

其他回答

PHP的DateTimeZone::listAbstrations()输出

此PHP方法返回一个包含一些“主要”时区(如CEST)的关联数组,这些时区本身包含更具体的“地理”时区(例如欧洲/阿姆斯特丹)。

如果您使用这些时区及其偏移/DST信息,请务必了解以下信息:

似乎每个时区的所有不同偏移量/DST配置(包括历史配置)都包含在内!

例如,欧洲/阿姆斯特丹可以在该函数的输出中找到六次。两次出现(偏移量1172/4772)是1937年之前使用的阿姆斯特丹时间;两个(1200/4800)用于1937年至1940年间使用的时间;两个(3600/4800)是1940年以来使用的时间。

因此,您不能依赖此函数返回的当前正确/正在使用的偏移量/DST信息!

如果您想知道某个时区的当前偏移量/DST,您必须执行以下操作:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

在处理存储在FAT32文件系统中的时间戳时要小心——它总是保存在本地时间坐标中(包括DST——请参阅msdn文章)。被那一块烧伤了。

还有一件事,确保服务器应用了最新的夏令时补丁。

去年,我们遇到了这样一种情况,北美用户在三周内的时间里,即使我们使用的是基于UTC的系统,我们的时间也总是比以前少一个小时。

最后证明是服务器。他们只需要应用最新的修补程序(Windows Server 2003)。

在处理数据库(特别是MySQL,但这适用于大多数数据库)时,我发现很难存储UTC。

默认情况下,数据库通常使用服务器日期时间(即CURRENT_TIMESTAMP)。您可能无法更改服务器时区。即使您能够更改时区,您也可能有第三方代码希望服务器时区是本地的。

我发现,只需在数据库中存储服务器日期时间,然后让数据库在SQL语句中将存储的日期时间转换回UTC(即UNIX_TIMESTAMP())就更容易了。之后,您可以在代码中使用日期时间作为UTC。

如果您100%控制服务器和所有代码,那么最好将服务器时区更改为UTC。

永远不要在没有UTC偏移(或时区参考)的情况下存储本地时间-如何不这样做的示例包括C¹中的FAT32和结构tm了解时区是一组UTC偏移(例如,冬季+0100,夏季+0200)切换发生的时间规则(可能会随着时间的推移而改变:例如,在20世纪90年代,欧盟将切换统一为3月和10月的最后一个星期日,标准时间02:00/夏令时03:00;之前成员国之间有所不同)。


¹struct tm的一些实现确实存储UTC偏移量,但这并未将其纳入标准。