Windows的FILETIME结构是否包含闰秒？

如果FILETIME包含闰秒，则不应该是这个问题。

它应该是：

在计算持续时间时，解释FILETIME （即FileTimeToSystemTime ）的人员，函数和库FileTimeToSystemTime包含闰秒？

简单的答案是“不” 。 FileTimeToSystemTime返回秒数为0..59 。

更简单的答案是：“ 当然不是，怎么可能？ ”

我的Windows 2000机器不知道自从发布以来，在十年内增加了两个闰秒。 它对FILETIME任何解释都是错误的。

最后，不是依靠逻辑，我们可以通过直接的实验观察来确定海报问题的答案：

 var systemTime: TSystemTime; fileTime: TFileTime; begin //Construct a system-time for the 12/31/2008 11:59:59 pm ZeroMemory(@systemTime, SizeOf(systemTime)); systemtime.wYear := 2008; systemTime.wMonth := 12; systemTime.wDay := 31; systemTime.wHour := 23; systemtime.wMinute := 59; systemtime.wSecond := 59; //Convert it to a file time SystemTimeToFileTime(systemTime, {var}fileTime); //There was a leap second 12/31/2008 11:59:60 pm //Add one second to our filetime to reach the leap second filetime.dwLowDateTime := fileTime.dwLowDateTime+10000000; //10,000,000 * 100ns = 1s //Convert the filetime, sitting on a leap second, to a displayable system time FileTimeToSystemTime(fileTime, {var}systemTime); //And now print the system time ShowMessage(DateTimeToStr(SystemTimeToDateTime(systemTime))); 

加一秒钟

 12/31/2008 11:59:59pm 

给

 1/1/2009 12:00:00am 

而不是

 1/1/2009 11:59:60pm 

QED

原来的海报可能不喜欢它，但上帝故意操纵它，以便一年不能被一整天整除。 他这样做只是为了搞砸程序员。

没有先决定的话，这个问题就不会有单一的答案：什么是Windows FILETIME实际计算的？ 微软的文档说，它自1601年UTC以来计数为100纳秒，但这是有问题的。

在1960年以前，没有任何形式的国际协调时间存在。在1964年以前的任何文献中都没有出现UTC的名称。UTC的名称直到1970年才存在，但情况变得更糟。 皇家格林威治天文台直到1676年才建立起来，所以即使试图将FILETIME译成格林尼治标准时间也没有明确的含义，只有在那个时候摆钟准确的擒纵才能开始给出1秒的准确度。

如果FILETIME被解释为平均太阳秒数，则从1601开始的闰秒数为零，因为UT没有闰秒。 如果FILETIME被解释为已经有原子计时器，那么自1601年以来的闰秒数约为-60（这是负60闰秒）。

那是古老的历史，自从原子计时以来呢？ 没有比这更好的了，因为各国政府并没有区分平均太阳秒和SI秒。 十年来，ITU-R一直在讨论放弃闰秒，但尚未达成国际共识。 其中一部分原因可以在这个页面上的javascript中看到（也可以参见该页面上的Delta-T链接，了解古代历史的情节）。 由于各国政府没有明确区分，所以任何界定自1972年以来的秒数的尝试都会根据某些司法管辖区的法律发生无效的风险。 与ITU-R的代表一样，POSIX委员会的人员也意识到了这一复杂性。 在解决外交问题之前，除非国家政府和国际标准在平均太阳能和国际标准时间之间作出明确的区分和选择，否则计算机标准可望效仿。

以下是关于为什么选择特定日期的更多信息。

自1601年1月1日起，FILETIME结构以100纳秒的间隔记录时间。为什么选择这个日期？

公历是以400年为周期运行的，1601年是在设计Windows NT时处于活跃状态的第一年。 换句话说，它是选择使数学出来很好。

我其实有Dave Cutler的电子邮件证实了这一点。

闰秒被IERS不可预知地添加。 自1972年以来，已经增加了23秒，当UTC和闰秒被定义。 维基百科说：“因为地球自转速度是长期不可预测的，所以提前6个月以上就不可能预测到它们的需要。”

由于您必须保留插入闰秒的历史记录，并且不断更新操作系统以保留插入时间的参考，并且差异很小，所以不要期望通用操作系统弥补闰秒。

另外，与UTC相比，PC中简单电子时钟的常规时钟漂移比闰秒所需的补偿要大得多。 如果您需要精确度来补偿闰秒，则不应使用高度不准确的PC时钟。

一个非常粗略的总结：

UTC =（原子时间）+（闰秒）~~（平均太阳时间）

MS的文档说，具体来说，“UTC”，所以应该包括闰秒。 和MS一样，你的里程可能会有所不同。

根据这个评论窗户是完全不知道闰秒。 如果你将24 * 60 * 60秒加到今天1:39:45的FILETIME中，那么无论如何，你都会得到一个代表明天1:39:45的FILETIME。