c++ - 是否存在 difftime 计算闰秒的实际系统？

Question

C 标准 (ISO/IEC 9899) 规定:

7.2x.2.2 The difftime function

Synopsis

   #include <time.h>
   double difftime(time_t time1, time_t time0);

Description

The difftime function computes the difference between two calendar times: time1 - time0.

Returns

The difftime function returns the difference expressed in seconds as a double.

如果结果说明 leap seconds 或不说明，这会使其变得模棱两可(我猜是故意的)。差异(从 1970 年到 2015 年 7 月比较时为 26 秒)在某些应用程序中很重要。

C 标准库的大多数实现不考虑闰秒，这是可测试的:以下(故意简洁)代码倾向于输出 leap seconds accounted from 2000/01/01 to 2015/01/01: 0(如果 mktime 无效，则为 -473385600)，在此期间确实有 3 个闰秒。

#include <time.h>
#include <stdio.h>
struct tm t0,t1; // globals, thus initialized to zero
int main(void) {
  t0.tm_year  = 2000-1900;         // from 2000
  t1.tm_year  = 2015-1900;         // to   2015
  t0.tm_mday  = t1.tm_mday  = 1;   // first day of January   
  printf("leap seconds accounted for from 2000/01/01 to 2015/01/01: %.0f\n",
    difftime( mktime(&t1), mktime(&t0) ) - 86400.*(365.*15+4) );
  return 0;
}

是否存在带有计算闰秒的 C/C++ 标准库的实际系统，可以使用 mktime 和 difftime 的这种组合进行测试？

换句话说:许多现代操作系统都通过更新机制了解有关法定时间的立法变更，并且像 localtime 这样的标准库函数确实使用该信息并相应地计算它们的结果。完全有可能，并且据我所知符合 C 标准，类似的更新机制会通知操作系统过去和不久的将来的闰秒，并且 difftime 或 mktime 使用该信息。我的问题是周围是否有这样的系统和标准库，因为这会影响某些代码。

---

以下 comment :上下文是应该可移植到各种系统(从嵌入式到大型机，有些很旧)的代码，并决定何时(从调用时间开始的秒数，最多为 99999 的整数)一些必须根据(除了系统时间之外)给定的“自 2000 年 1 月 1 日以来在 UTC 午夜经过的秒数”和所需的操作时间来触发操作。 ±2 秒的误差(加上 UTC 引用的漂移)是可以容忍的。

现有代码使用 time、mktime 表示 2000/01/01 和 difftime 表示它们之间的差异，如下所示通过减去给定的。我想知道是否严重担心它可能会失败(并返回一些略微超出规定容差的东西；比如 4 在撰写本文时太低，并且还在增加)。我不是询问如何使代码可移植(一个选项是使用 gmtime(time(NULL)) 并使用显式代码计算其余部分)。

主要问题的措辞没有time，以避免time是否考虑时区的不同可移植性问题。

Answer 1

这是一个信息问题，但实际上是一个物理问题。

第一个信息 View :

通用操作系统，了解 UTC 时间，最终了解本地时间。他们假设引用是 UTC 时间并且所有分钟都恰好持续 60 秒。他们使用闰秒来补偿本地时间源( quartz )和外部引用之间的误差。从他们的角度来看，滑动时钟的校正与真正的(物理)闰秒没有区别。出于这个原因，他们不知道 true 闰秒，目前忽略它们

现在的物理 View (引用维基百科上的 UTC 和 TAI):

1955年，铯原子钟发明。这提供了一种比天文观测更稳定、更方便的计时方式。

[1972 年，TAI(法语 Temps Atomique International)被定义，仅基于铯原子钟。]在 1970 年代，很明显参与 TAI 的时钟由于引力时间而以不同的速率滴答作响膨胀，因此组合的 TAI 标度对应于各种时钟高度的平均值。从 Julian Date 2443144.5(1977 年 1 月 1 日 00:00:00)开始，对所有参与时钟的输出应用了更正，以便 TAI 对应于平均海平面(大地水准面)的本征时间。因为时钟平均高于海平面，这意味着 TAI 放慢了大约万亿分之一。由于潮汐减速，地球的自转速度正在非常缓慢地下降；这增加了平均太阳日的长度。 SI 秒的长度是根据星历时间的秒数校准的，现在可以看出它与 Simon Newcomb 分析的 1750 年至 1892 年间观察到的平均太阳日有关系。因此，SI 秒接近 19 世纪中叶平均太阳日的 1/86400。在更早的几个世纪，平均太阳日短于 86,400 SI 秒，而在最近几个世纪，它长于 86,400 秒。接近 20 世纪末，平均太阳日的长度(也简称为“日长”或“LOD”)约为 86,400.0013 秒。出于这个原因，UT 现在比 TAI“慢”了 1.3 毫秒/天的差异(或“过量”LOD)。

第一个闰秒出现在 1972 年 6 月 30 日。从那时起，闰秒平均每 19 个月出现一次，总是在 6 月 30 日或 12 月 31 日。截至 2015 年 7 月，总共有 26 个闰秒，均为正，使 UTC 落后 TAI 36 秒。

TL/DR 因此，如果您真的需要它，您将必须获取在(物理)UTC 中引入 26 闰秒的日期，并在相关时手动获取它们。据我所知，目前的操作系统和标准库都没有处理它们。

闰秒引入日期表在 http://www.ietf.org/timezones/data/leap-seconds.list 以纯文本形式维护。