Windows FILETIME结构包括闰秒？

StackOverflow https://stackoverflow.com/questions/130573

题

的 FILETIME 结构 数月1 1601(大概是该开始的那一天)根据Microsoft的文件，但这不会包括闰秒？

有帮助吗？

解决方案

问题不应该是 FILETIME 包含闰秒。

应该是：

  

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

简单的答案是“no”。 FileTimeToSystemTime 以 0..59 的形式返回秒数。

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

我的Windows 2000机器不知道自发布以来十年内增加了2个闰秒。它对 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

Q.E.D。

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

其他提示

这里提供了更多有关特定原因的信息选择日期。

  

FILETIME结构记录时间   100纳秒间隔的形式   从1601年1月1日起。为什么会这样   选择日期？

     

格里高利历是以a为准   400年周期，1601是第一个   活跃的周期年份   Windows NT的时间   设计的。换句话说，它是   选择让数学出来   很好。

     

我实际上收到了戴夫的电子邮件   卡特勒证实了这一点。

如果没有先决定，这个问题就没有单一答案：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委员会的成员也是如此。在制定外交问题之前，在国家政府和国际标准在平均太阳能和SI秒之间作出明确的区分和选择之前，计算机标准几乎没有希望效仿。

IERS不可预测地添加了闰秒。自1972年以来，已经定义了23秒，当时定义了UTC和闰秒。维基百科说“因为从长远来看地球的轮换速度是不可预测的，所以不可能提前六个月预测它们的需要。”

由于您必须保留插入闰秒的历史记录，并不断更新操作系统以保留插入时间的参考，并且差异非常小，所以不要指望一般性 - 用于补偿闰秒的操作系统。

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

这个问题的答案使用的是没有，但是已经改变： 是的，排序，有时候...

每 Windows网络团队的博客的文章:

开始在服务器2019和Windows10月[2018年]更新时间Api会现在将考虑到所有闰秒的操作系统是知道的，当它转化FILETIME到SystemTime.

因为已经无闰秒发出时间以来的这个功能正在增加，操作系统仍然不知道有任何闰秒钟。但是，当下一个正式的飞跃，第二，使得它的方式融入世界，Windows计算机有这种新的功能启用将保持它的轨道，和这样 FILETIME 值将抵消的数量闰秒的计算机上的时候他们解释。

该博客上来描述：

没有更改FILETIME.它仍然代表人数的100纳秒的时间间隔开始以来的的时代。发生了什么变化是解释这些，当它转化为SYSTEMTIME和回。这是一个列表中的影响Api:

  • GetSystemTime
  • GetLocalTime
  • FileTimeToSystemTime
  • FileTimeToLocalTime
  • SystemTimeToFileTime
  • SetSystemTime
  • SetLocalTime

在此之前释放，SYSTEMTIME有有效值wSecond之间0和59。SYSTEMTIME现在已经更新，允许一个值的60，所提供的年、月、日代表日在其中一个飞跃，第二是有效的。

...

为了收到的60第二SYSTEMTIME结构的进程必须明确选择。

注意，巴勒斯坦被占领土中适用于该行为在功能上列出的如何 FILETIME 是映射到 SYSTEMTIME.不管你是否选择加入或不，操作系统将仍然偏 FILETIME 值根据闰秒它是知道的。

关于兼容性，该条称：

应用程序依赖于第3个方框架应该确保框架的执行上窗户也被叫到正确的Api来计算正确的时间，或者其他应用程序将有错误的时间出报告。

并且还提供了一个链接到 一个较早的后 它描述了如何禁止的整个要素，具体如下：

...你可以恢复现有的操作系统的行为和禁止闰秒跨过委员会通过添加以下的注册处的关键：

  • HKLM:\SYSTEM\CurrentControlSet\Control\LeapSecondInformation
  • 类型："数据"
  • 名称：启用
  • 价值： 0 禁用系统范围的设置
  • 价值： 1 使系统范围的设置

接下来，重新启动系统。

非常粗略的总结：

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

MS文档特别指出“UTC”，因此应包括闰秒。与MS一样，您的里程可能会有所不同。

根据此评论窗口完全没有意识到闰秒。如果你向今天1:39:45的FILETIME添加24 * 60 * 60秒，你将获得一个代表明天1:39:45的FILETIME，无论如何。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top