是否有实际的系统，其中difftime占闰秒？ [英] Are there actual systems where difftime accounts for leap seconds?

问题描述

C标准（ISO / IEC 9899）规定：

7.2x.2.2 difftime function

$ b

p $ p> #include< time.h>
double difftime（time_t time1，time_t time0）;


说明

difftime 函数计算两个日历时间之间的差值： time1 - time0 。

返回

difftime 以秒为单位以 double 表示。

，有意），如果结果说明了闰秒。差异（从1970年到2015年7月比较时为26秒）在某些应用程序中很重要。

大多数C标准库的实现不考虑闰秒，可测试：以下（有意简洁）代码倾向于输出从2000/01/01到2015/01/01：0 （或 -473385600 如果 mktime 无效），那段时间内确实有3闰秒。

  #include< time.h> 
 #include< stdio.h> 
 struct tm t0，t1; //全局变量，从而初始化为零
 int main（void）{
 t0.tm_year = 2000-1900; // from 2000 
 t1.tm_year = 2015-1900; // to 2015 
 t0.tm_mday = t1.tm_mday = 1; // January of January 
 printf（闰秒从2000/01/01到2015/01/01：％.0f \\\
，
 difftime（mktime（& t1） ，mktime（& t0）） -  86400。*（365. * 15 + 4））; 
 return 0; 
} 
  

是否有实际的系统使用C / C ++标准库来计算闰秒，使用 mktime 和 difftime ？

的组合， p>否则说：许多现代操作系统通过更新机制意识到法律时间的立法变化，并且标准库函数 localtime 确实使用该信息并计算其结果因此。这是完全可能的，并且C标准符合我所看到的，类似的更新机制通知操作系统过去和接近未来的闰秒，并且 difftime 或 mktime 使用该信息。我的问题是，是否有这样的系统和标准库，因为这将影响一些代码。

---

=http://stackoverflow.com/q/31313157/903600#comment50614565_31313157>注释：上下文是应该可移植到各种系统的代码（从嵌入式到大型机，一些很老），并决定当（从呼叫时间起的秒数，作为至多99999的整数）一些动作必须被触发，基于（除了系统时间之外）给定的数量（非跳跃） 2000/01/01 at midnight in UTC和所需的动作时间。

现有的代码使用时间的一个简单的组合对于2000/01/01的， mktime 和这些之间的区别的 difftime 然后减去给定值。我不知道是否有严重的担心，它可能失败（并返回一些略微偏离所述的宽容;如4太低在写作时间，并增加）。我不要求如何使代码可移植（一个选项将使用 gmtime（time（NULL））并使用显式计算其余代码）。

主要问题是没有 time ，以避免超出范围的不同的可移植性问题if time 帐户的时区。

解决方案

，但实际上是一个实体。

第一个信息视图：

时间和最终本地时间。他们假设引用是UTC时间，并且所有分钟最后正好是60秒。它们使用闰秒来补偿它们的本地时间源（石英）和外部参考之间的误差。从它们的观点来看，滑动时钟的校正与真实（物理）闰秒之间没有差别。因此，他们不知道真正的闰秒，目前忽略它们

现在物理视图（参考 UTC 和 TAI on wikipedia）：

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

[1972年，TAI（法国Temps Atomique International）基于铯原子钟]。在20世纪70年代，显然参与TAI的时钟由于重力时间膨胀而以不同的速率滴答，因此组合的TAI标度对应于各个时钟的高度的平均值。从朱利安日期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.3ms /天的差（或过量LOD）。

第一个闰秒发生在30天从那时起，闰秒平均每19个月发生一次，总是在6月30日或12月31日。截至2015年7月，总共有26闰秒，都是积极的，比TAI落后UTC 36秒。

TL / DR如果你真的需要它，您将必须获得在（物理）UTC引入26闰秒的日期，并在相关时手动进行。 AFAIK，没有当前的操作系统或标准库处理它们。

闰秒的介绍日期表保持为纯文本 http://www.ietf.org/timezones/data/leap-seconds.list

The C standard (ISO/IEC 9899) states:

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.

This leaves it ambiguous (I guess, intentionally) if the result accounts for leap seconds or not. The difference (26 seconds when comparing from 1970 to July 2015) matters in some applications.

Most implementations of the C standard library do not account for leap seconds, and this is testable: the following (intentionally terse) code tends to output leap seconds accounted for from 2000/01/01 to 2015/01/01: 0 (or -473385600 if mktime is inoperative), when there really has been 3 leap seconds over that period.

#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;
}

Are there actual systems with a C/C++ standard library that accounts for leap seconds, as testable using such combination of mktime and difftime ?

Otherwise said: many modern operating systems are made aware of legislative changes about legal time by an update mechanism, and standard library functions like localtime do use that information and compute their result accordingly. It would be entirely possible, and C-standard-conformant as far as I see, that a similar update mechanism informs the operating system of the past and near future leap seconds, and that either difftime or mktime use that information. My question asks if there are such systems and standard libraries around, because that would impact some code.

---

Following comment: the context is code that should be portable to a variety of systems (from embedded to mainframes, some quite old) and decides when (in seconds from the time of the call, as an integer at most 99999) some action has to be triggered, based (in addition to the system time) on the given "number of" (non-leap) "seconds elapsed since 2000/01/01 at midnight in UTC" and the desired time of the action. An error of ±2 seconds (in addition to the drift of the UTC reference) is tolerable.

Existing code uses a trivial combination of time, mktime for 2000/01/01, and difftime for the difference between these, followed by subtraction of the given. I wonder if there is serious concern that it could fail (and return something slightly out of the stated tolerance; like 4 too low at time of writing, and increasing). I'm not asking how to make the code portable (one option would be using gmtime(time(NULL)) and computing the rest using explicit code).

The main question is worded without time to keep out of scope the different portability issue of if time accounts for time zone.

解决方案

This is asked as an informatic question, but it is really a physical one.

First informatic view :

Common operating systems, know about UTC time and eventually localtime. They assume that the reference is the UTC time and that all minutes last exactly 60 seconds. They use leap seconds to compensate errors between their local time source (a quartz) and an external reference. From their point of view, there is no difference between a correction of a sliding clock and a true (physical) leap seconds. For that reason they are not aware of true leap seconds and currently ignore them

Now physical view (ref on UTC and TAI on wikipedia) :

In 1955, the caesium atomic clock was invented. This provided a form of timekeeping that was both more stable and more convenient than astronomical observations.

[In 1972, the TAI (Temps Atomique International in french) was defined, only based on the caesium atomic clock.] In the 1970s, it became clear that the clocks participating in TAI were ticking at different rates due to gravitational time dilation, and the combined TAI scale therefore corresponded to an average of the altitudes of the various clocks. Starting from Julian Date 2443144.5 (1 January 1977 00:00:00), corrections were applied to the output of all participating clocks, so that TAI would correspond to proper time at mean sea level (the geoid). Because the clocks had been on average well above sea level, this meant that TAI slowed down, by about one part in a trillion. Earth's rotational speed is very slowly decreasing because of tidal deceleration; this increases the length of the mean solar day. The length of the SI second was calibrated on the basis of the second of ephemeris timeand can now be seen to have a relationship with the mean solar day observed between 1750 and 1892, analysed by Simon Newcomb. As a result, the SI second is close to 1/86400 of a mean solar day in the mid‑19th century. In earlier centuries, the mean solar day was shorter than 86,400 SI seconds, and in more recent centuries it is longer than 86,400 seconds. Near the end of the 20th century, the length of the mean solar day (also known simply as "length of day" or "LOD") was approximately 86,400.0013 s. For this reason, UT is now "slower" than TAI by the difference (or "excess" LOD) of 1.3 ms/day.

The first leap second occurred on 30 June 1972. Since then, leap seconds have occurred on average about once every 19 months, always on 30 June or 31 December. As of July 2015, there have been 26 leap seconds in total, all positive, putting UTC 36 seconds behind TAI.

TL/DR So, if you really need it, you will have to get the date at which the 26 leap seconds were introduced in (physical) UTC and and them manually when relevant. AFAIK, no current operating system nor standard library deal with them.

A table for introduction date of leap seconds is maintained as plain text at http://www.ietf.org/timezones/data/leap-seconds.list

这篇关于是否有实际的系统，其中difftime占闰秒？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！