C标准(ISO / IEC 9899)规定:
7.2x.2.2
difftime
函数概要
#include double difftime(time_t time1, time_t time0);
描述
difftime
函数计算两个日历时间之间的差异:time1 - time0
。返回
difftime
函数以秒为单位返回以秒表示的差异。
如果结果占闰秒 ,则会使其模糊不清(我猜是故意的)。 在某些应用中,差异(从1970年到2015年7月比较时为26秒)很重要。
C标准库的大多数实现都不考虑闰秒,这是可测试的:以下(故意简洁)代码倾向于输出leap seconds accounted for from 2000/01/01 to 2015/01/01: 0
(或-473385600
)的leap seconds accounted for from 2000/01/01 to 2015/01/01: 0
-473385600
如果mktime
不起作用),那段时间内确实有3个闰秒。
#include #include 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: %.0fn", difftime( mktime(&t1), mktime(&t0) ) - 86400.*(365.*15+4) ); return 0; }
是否存在具有C / C ++标准库的实际系统,这些库可以计算闰秒,使用mktime
和difftime
这样的组合可以测试?
否则说:许多现代操作系统通过更新机制了解法律时间的立法变化,而像localtime
这样的标准库函数确实使用该信息并相应地计算其结果。 完全可能,并且就我所见的C标准一致,类似的更新机制通知操作系统过去和将来的闰秒,并且difftime
或mktime
使用该信息。 我的问题是询问是否存在这样的系统和标准库,因为这会影响某些代码。
以下评论 :上下文是应该可以移植到各种系统的代码(从嵌入式到大型机,有些很旧)并且决定何时(从调用时起的几秒钟内,作为最多99999的整数)某些操作必须被触发,基于(除了系统时间之外)给定的“数量”(非飞跃)“自2000/01/01以来在UTC午夜过去的秒数”以及所需的行动时间。 ±2秒的误差(除了UTC参考的漂移之外)是可以容忍的。
现有代码使用time
的简单组合,2000/01/01的mktime
和difftime
之间的差异,然后减去给定的。 我想知道是否存在严重的问题,它可能会失败(并返回略微超出规定容差的东西;就像写作时的4太低,并且增加)。 我不是要问如何使代码可移植(一个选项是使用gmtime(time(NULL))
并使用显式代码计算其余部分)。
如果time
占时区的话,主要问题是没有time
不同的可移植性问题。
这是一个信息问题,但它实际上是一个物理问题。
第一个信息观点:
常见的操作系统,了解UTC时间,最终了解本地时间。 他们假设参考是UTC时间,并且所有分钟都持续60秒。 它们使用闰秒来补偿其本地时间源(石英)和外部参考之间的误差。 从他们的观点来看,滑动时钟的校正与真实(物理)闰秒之间没有区别。 出于这个原因,他们不知道真正的闰秒,目前忽略它们
现在物理视图(参考维基百科上的UTC和TAI ):
1955年,发明了铯primefaces钟。 这提供了一种比天文观测更稳定和更方便的计时forms。
[1972年,TAI(Temps Atomique International in French)被定义,仅基于铯primefaces钟。]在20世纪70年代,由于引力时间膨胀,参与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秒。 出于这个原因,UT现在比TAI“慢”,差异(或“超额”LOD)为1.3毫秒/天。
第一次闰秒发生在1972年6月30日。从那以后,平均每19个月发生一次闰秒,总是在6月30日或12月31日。 截至2015年7月,总共有26个闰秒,全部为正,将UTC落后于TAI 36秒。
TL / DR所以,如果你真的需要它,你必须得到(物理)UTC引入26闰秒的日期,并在相关时手动获取它们。 AFAIK,没有当前的操作系统,也没有标准库处理它们。
闰秒的引入日期表格以纯文本forms保存在https://www.ietf.org/timezones/data/leap-seconds.list
以上就是c/c++开发分享是否存在difftime占闰秒的实际系统?相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注计算机技术网(www.ctvol.com)!)。
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/c-cdevelopment/562392.html