c++ - difftime占秒的实际系统吗？

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

如果结果是否为leap seconds，这将导致模棱两可(我想是有意的)。差异(从1970年到2015年7月为26秒)在某些应用中很重要。

C标准库的大多数实现都不考虑leap秒，这是可测试的:当在这段时间内确实有3个leap秒时，以下(有意的)简短代码倾向于输出leap seconds accounted for from 2000/01/01 to 2015/01/01: 0(如果-473385600不起作用，则倾向于mktime)。。

#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++标准库解决leap秒的系统，可以使用mktime和difftime的这种组合进行测试？

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

comment之后:上下文是应移植到各种系统(从嵌入式系统到大型机，有些已经很老了)的代码，并决定何时(某些情况下，从调用开始，以秒为单位，最大为99999的整数)。 (基于系统时间)基于给定的“(无跳)”“自UTC午夜2000/01/01起经过的秒数”和所需的操作时间触发触发。 ±2秒的误差(除了UTC引用的漂移)是可以容忍的。

现有代码使用time，2000/01/01的mktime和difftime的微不足道的组合来区别它们，然后减去给定值。我不知道是否会严重担心它会失败(并且返回一些超出规定的容忍度；例如在撰写本文时4太低，并不断增加)。我不是在问如何使代码可移植(一种选择是使用gmtime(time(NULL))，其余使用显式代码计算)。

主要问题的措词是不带time，以使time占时区不同的可移植性问题不在范围之内。

最佳答案

这是一个信息问题，但实际上是一个物理问题。
第一信息观:
常见的操作系统了解UTC时间，并最终了解本地时间。他们假设引用时间是UTC时间，而所有分钟都恰好持续60秒。他们使用leap秒补偿本地时间源( quartz )和外部基准之间的误差。从他们的 Angular 来看，滑动时钟的校正与真实(物理)leap秒之间没有区别。因此，他们不知道真正的leap秒，目前忽略它们
现在是物理 View (请引用UTC和Wikipedia上的TAI):
1955年，发明了铯原子钟。这提供了一种比天文观测更稳定，更方便的计时方式。
[1972年，仅基于铯原子钟才定义了TAI(法语为Temps Atomique International。)在1970年代，很明显，由于重力时间膨胀，参与TAI的钟以不同的速率滴答，并且因此，组合的TAI标尺对应于各个时钟的高度平均值。从儒略日期2443144.5(1977年1月1日00:00:00)开始，对所有参与时钟的输出进行了更正，以使TAI对应于平均海平面(大地水准面)上的适当时间。由于时钟的平均水平远高于海平面，这意味着TAI的速度减慢了大约一万亿分之一。
由于潮汐减速，地球的旋转速度非常缓慢地降低。这增加了平均太阳日的长度。 SI秒的长度是根据星历时间校准的，现在可以看出它与1750年至1892年之间观测到的平均太阳日有关系，这是由Simon Newcomb分析的。结果，SI的秒数接近19世纪中叶平均太阳日的1/86400。在较早的世纪中，平均太阳日短于86,400 SI秒，而在较新的世纪中，太阳日均长于86,400秒。在20世纪末，平均太阳日的长度(也简称为“日长”或“LOD”)约为86,400.0013 s。因此，UT现在比TAI“慢”了1.3毫秒/天的差异(或“过量” LOD)。
第一次leap秒发生在1972年6月30日。此后，leap秒平均大约每19个月出现一次，通常发生在6月30日或12月31日。截至2015年7月，总共有26个leap秒，均为正数，使UTC落后TAI 36秒。
TL / DR因此，如果确实需要，则必须获取在(物理)UTC中引入26 the秒的日期，并且在相关时手动进行设置。 AFAIK，当前的操作系统或标准库都没有处理它们。
在http://www.ietf.org/timezones/data/leap-seconds.list上以纯文本形式保存of秒的引入日期表

Leap

c++ - difftime占秒的实际系统吗？