是否有实际的系统中difftime占闰秒？ [英] Are there actual systems where difftime accounts for leap seconds?
问题描述
C标准（ISO / IEC 9899）指出：
The C standard (ISO/IEC 9899) states:
7.2x.2.2的 difftime 函数
7.2x.2.2 The
difftimefunction
简介
#include <time.h>
double difftime(time_t time1, time_t time0);
说明
的 difftime 函数计算两个日历时间之间的区别：时间1 - 时间0/1/2
The difftime function computes the difference between two calendar times: time1 - time0.
返回
的 difftime 函数返回秒pssed方面的差异前$ P $一个双击。
The difftime function returns the difference expressed in seconds as a double.
这使得IT暧昧（我猜的，有意的）如果结果占闰秒或不。所不同的一些应用程序（从1970年比较，2015年7月，当26秒）的事项。
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.
C标准库的大多数实现不占闰秒，这是可测试：以下（有意简洁）code趋于输出闰秒占比从2000/01 / 01至2015年1月1日0 （或 -473385600 如果 mktime 不起作用），当有真的已经3闰秒在此期间。
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;
}
有没有用C / C ++标准库，占闰秒的实际系统中，如 mktime 的可测试使用这样的组合和 difftime ？
Are there actual systems with a C/C++ standard library that accounts for leap seconds, as testable using such combination of mktime and difftime ?
否则说：很多现代操作系统都意识到关于法定时间通过更新机制的立法变化，标准库函数如本地时间不要使用该信息，并计算它们的相应的结果。这将是完全有可能的，而且C-符合标准的，据我看到的，类似的更新机制通知过去和近期闰秒的操作系统，要么 difftime 或 mktime 使用该信息。我的问题询问是否有大约这样的系统和标准库，因为这会影响到一些code。
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.
现有code使用时间， mktime 为2000年1月1日一个平凡的结合， difftime 为它们之间的差，随后给定的减法。我不知道是否有严重的问题，它可能会失败（并返回东西稍稍偏出给出的误差的;像4太低，在写作的时间，并增加）。我的不的询问如何使code便携式（一个选项将使用 gmtime的（时间（NULL））和计算的休息使用显式code）。
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.
常见的操作系统，了解UTC时间，并最终本地时间。他们认为引用是UTC时间，所有持续数分钟正好60秒。他们使用闰秒到其本地时间源（石英）和外部基准之间补偿误差。从他们的观点来看，有一个滑动时钟的校正与一个真实的（物理）闰秒之间没有差别。出于这个原因，他们都没有意识到的真正的闰秒，目前忽略它们。
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
在1955年，铯原子钟的发明。这提供计时的一种形式，是既更稳定，比天文观测更方便。
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.
[1972年，TAI（Temps的国际原子法语）的定义，只是基于铯原子钟。在上世纪70年代，它是由于重力的时间变得清晰，参与TAI时钟以不同的速率滴答因此扩张，将合并的TAI规模相当于平均的各种时钟的高度的。从儒略历2443144.5（1977年1月1日00:00:00）开始，更正被应用到所有参与时钟输出，让TAI将在平均海平面（大地水准面）对应于适当的时候。因为时钟已经平均以及海平面以上，这意味着在TAI万亿放缓，大约一个部分。
地球的旋转速度，因为潮汐减速的速度非常缓慢下降;这增加了平均太阳日的长度。在SI的第二被校正的星历timeand的第二的基础上的长度现在可以看到有一个与1750和1892年之间观察到的平均太阳日，由西蒙纽康分析的关系。其结果是，在SI二是接近平均太阳日的八万六千四百分之一在19世纪中叶。在早期的几个世纪中，平均太阳日短于86,400 SI秒，在最近几个世纪以来它比86,400秒。近20世纪末，平均太阳日（也简称为日长或LOD）的长度大约为86,400.0013秒。出于这个原因，UT是现在由差大于TAI慢（或过剩的LOD）为1.3毫秒/天
[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.
第1972年闰六月二日发生于30从那时起，闰秒都在发生平均约每19个月一次，总是30六月和12月31日。自2015年7月，已经有26闰秒的总，所有的正，把UTC36秒背后TAI。
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所以，如果你真的需要它，你将获得在其中的26个闰秒是在（物理）UTC推出日期，并将其相关时手动。据我所知，目前没有操作系统，也没有标准库处理这些问题。
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.
一个用于闰秒引入日期表保持为纯文本在 HTTP： //www.ietf.org/timezones/data/leap-seconds.list
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屋！
