.Net 的 DateTime 方法能够识别闰秒吗?
今年六月即将到来的闰秒让我想知道.Net框架是否支持闰秒?额外的一秒将在 6 月 30 日最后一秒之后插入,以便 UTC 正式发布:
2012 June 30, 23h 59m 59s
2012 June 30, 23h 59m 60s
2012 July 1, 0h 0m 0s
.Net 框架是否能够处理此问题?如果Windows 不支持闰秒,这还重要吗?这是否会影响在支持闰秒的操作系统上运行的单声道应用程序?
编辑:
为了对此进行扩展,我设想了一个场景,其中 Linux 上基于 Java 的解决方案(可感知闰秒)调用 .Net Web 服务,传递有效时间戳的内容在 Java 中可以,但在 .Net 中超出范围。是否有任何框架可以满足它(也许像 Noda Time)?
With a Leap Second on the horizon for June this year it got me wondering whether the .Net framework is leap second aware? The extra second is to be inserted after the last second of June 30th so UTC will officially be:
2012 June 30, 23h 59m 59s
2012 June 30, 23h 59m 60s
2012 July 1, 0h 0m 0s
Is the .Net framework capable of handling this? Does it even matter if Windows is not Leap Second aware? Will this affect apps in mono running on O/S's that are Leap Second aware?
EDIT:
To expand on this a little bit i'm envisioning a scenario where a Java based solution on Linux (which is Leap Second aware) calls a .Net Web Service passing in something that is a valid timestamp in Java but is out of bounds for .Net. Are there any frameworks that cater for it (Like Noda Time perhaps)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不 -
来源:http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx
No -
Source: http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx
.Net DateTime 没有闰秒的规定,而仅依赖于操作系统时间。 Windows 完全不知道闰秒(1)(2),因此只有从接收到的时间概念它的 NTP 主服务器(我相信非域连接计算机的默认值是 time.windows.com),这是可能提供 UTC,包括闰秒。
另请参阅我对“在 C# 中计算未来纪元时间”的回答”其中有更多细节。
The .Net DateTime has no provisions for Leap Seconds, but will simply rely on the OS time. Windows is blissfully unaware of Leap Seconds(1)(2), and so will just have the notion of time as it receives it from its NTP master (I believe the default for a non-domain connected machine is time.windows.com), which is probably serving up UTC including leap seconds.
See also my answer to "Calculating Future Epoch Time in C#" which goes into more details.