随着Win 10 Oct 2018更新,Windows有了leap秒的意识。 .NET的DateTime也是吗? [英] With the Win 10 Oct 2018 update, Windows is leap second aware. Is .NET's DateTime, too, now?

查看:102
本文介绍了随着Win 10 Oct 2018更新,Windows有了leap秒的意识。 .NET的DateTime也是吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

2012年,SO上存在一个问题,即.NET的DateTime是否能够识别leap秒。 [1]答案是否定的。

In 2012, there was a question here on SO, whether .NET's DateTime are capable of recognizing leap seconds. [1] The answer was no.

文档仍然明确指出不是。 [2]

The documentation is still explicitly stating that it is not. [2]

但是,Windows Server 2019和Windows 10 October 2018更新使 Windows本身跃居第二。 [3]

However, Windows Server 2019 and the Windows 10 October 2018 update made Windows itself leap second aware. [3]

这引出了一个问题:.NET现在固有地second秒了吗?更具体地说:我是否可以通过选择加入来使 DateTime 结构也跃居第二位?

This begs the question: is .NET inherently leap second aware now? More specifically: can I make my DateTime structures leap second aware as well, by somehow opting in?

编辑:

来自MS Word文档,标题为 Quest:在Windows上编写飞跃的第二感知应用程序。 [4](我强调):

From a MS Word document titled "Quest: Write a Leap Second Aware Application on Windows" [4] (emphasis by me):


已知问题:已知某些框架在a秒发生后错误地计算了
的时间。例如,.NET Framework使用其自己的
内部逻辑来确定现在的时间。它的逻辑不能解释
代表leap秒。因此,在将
操作系统引入a秒后, System.DateTime.Now.ToString()的输出将使
提前本地系统时间的一秒。 (我们正在与.NET框架团队
合作。)

从[5]开始:


已知某些应用程序通过假设
一分钟总有60秒来错误地计算时间。由于leap秒可以改变
的这种行为,因此在
事件中它们会不适当地记录时间。例如(在撰写本文时):

Some applications are known to calculate time incorrectly by assuming that there are always 60 seconds in a minute. Since leap seconds can change this behavior, they will improperly record the time during this event. For example (at the time of writing):

.NET Framework使用
自己的内部逻辑来确定现在是什么时间,而
却不算leap秒。结果,依靠
.NET Framework的PowerShell在使用
Get-Date

.NET Framework uses its own internal logic to determine what time it is and does not account for leap seconds. As a result, PowerShell, which relies on the .NET Framework, will not report the 61st second (number 60) when using Get-Date

Event Viewer时不会报告第61秒(数字60) :活动日期将错误地记录
。但是,事件元数据将正确记录系统
的时间(显示第60秒)。

Event Viewer: The date of the event will be incorrectly recorded. However, the event metadata will properly record the system time (showing the 60th second).

注意:这些团队正在努力更新其软件以使用
在处理leap秒时更为合适

因此,.NET似乎在将来的某个时候会leap秒。因此,我不会将其发布为解决方案。

So it seems that .NET will be leap second aware some time in the future. Thus I will not post this as the solution.

[1]

[1] Are .Net's DateTime methods capable of recognising a Leap Second?

[2] https://docs.microsoft.com/ zh-cn / dotnet / api / system.datetime.ticks?redirectedfrom = MSDN& view = netframework-4.8#System_DateTime_Ticks

[3] https://support.microsoft.com/zh-CN/help/2722715 / support-for-the-leap-second

[4] https://aka.ms/Dev-LeapSecond (MS Word)

[4] https://aka.ms/Dev-LeapSecond (MS Word)

[5] https:// ak a.ms/ITPro-LeapSecond (MS Word)

[5] https://aka.ms/ITPro-LeapSecond (MS Word)

推荐答案


[H]澄清了.NET(4.7.2版)如何在支持the秒的Windows
版本上工作(例如Windows 10 RS5
版本):

[H]ere is some clarification how the .NET (version 4.7.2) work on the version of Windows that support the leap seconds (i.e. Windows 10 RS5 release):

DateTime(DT)和DateTimeOffset(DTO)在
如何存储时间单位以及如何存储方式方面没有改变在此类设备上运行。这些类型仅
存储滴答,滴答为100纳秒。在
个刻度和日期/时间部分(例如年月,日,小时,分钟,秒,
毫秒)之间进行转换时,始终假定分钟为60秒,而不能为
61秒。即在跳动或
转换中不计算leap秒。

DateTime (DT) and DateTimeOffset (DTO) are not changed in how it stores the time units and how operate on such units. These types just store ticks and the tick is 100 nanoseconds. When converting between ticks and date/time parts (e.g. year month, day, hour, minute, second, millisecond) it always assumes the minute is 60 seconds and cannot be 61 seconds. i.e. no leap seconds counted in the ticks or in the conversion.

在DT和DTO上调用Now属性时,我们将最终以
调用Windows API(例如GetSystemTimeAsFileTime)。
GetSystemTimeAsFileTime在那里计算了the秒。因此,.NET
在启用the秒功能的系统上运行时会采取额外的措施,以便
通过调用更多Windows API来获取准确的时间,该API可以报告
系统时间以确保.NET报告时间与
系统同步。 .NET仍在调用GetSystemTimeAsFileTime以便
获得更精确的时间(准确度为100纳秒)。

When calling Now property on DT and DTO, we'll end up calling Windows API (e.g. GetSystemTimeAsFileTime). GetSystemTimeAsFileTime has the leap seconds counted there. So, .NET is doing extra step when running on the leap seconds enabled system to get the exact time by calling more Windows API which can report the system time to ensure .NET reported time is synchronized with the system. .NET still calling GetSystemTimeAsFileTime for the sake of getting more precise time (which is 100 nanoseconds accuracy).

如果
Windows向我们报告第二个数字60(这是a秒),. NET
将假定这是最后一个秒在这一分钟内,将其用作
的第二秒59,以使其与DT和DTO无缝协作,因为这些类型
不知道leap秒。

In case Windows report to us a second number 60 (which is a leap second), .NET will assume this is the last second in that minute and use it as a second 59 to make it work seamlessly with DT and DTO as these types not aware of leap seconds.

如果有人尝试以
的秒数(60)创建DT或DTO,.NET将首先通过调用Windows API来检查此
是有效的leap秒,然后将其转换为第二个数字59。如果
不是有效的leap秒,则将引发异常。

If someone try to create a DT or DTO with a leap second (60), .NET will check first by calling Windows API if this is a valid leap second then convert it to second number 59. If it is not valid leap second, then we'll throw exception.

.NET并未更改
DT和DTO的工作原理以实现应用程序兼容性,因为我们
知道许多用户在进行相同的假设他们的代码打勾
的分钟总是60秒。而且在不同系统
中的滴答声不能表示不同的时间。让我知道如果您还有其他问题
或需要更多说明

.NET didn’t change how DT and DTO work for the sake of application compatibility as we know many users doing the same assumptions in their code that ticks always has the minute is 60 seconds. And ticks in different system cannot mean different time. Let me know if you have any more questions or you need more clarification

来源: https://github.com/dotnet/dotnet-api-docs/issues/966#issuecomment -434440807

这篇关于随着Win 10 Oct 2018更新,Windows有了leap秒的意识。 .NET的DateTime也是吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆