日期时间精度？

Question

< p > （忽略优化编译器标志）

这段代码在某些系统上可能会进入该块吗？

if (Datetime.Now!=Datetime.Now)
{
 ...
}

我的意思是，它如何评估这里的值？（按顺序吗）？

是否存在任何情况，其中条件可能为真？

再次强调，请忽略优化标志。

- Royi Namir

---

在一个非常慢的系统上，我猜你只需要在调用之间加入1个tick的延迟就可以使它们不同了。 - leppie

我喜欢这个回答：https://dev59.com/GHI95IYBdhLWcg3wzhZ9#2143784 - V4Vendetta

@leppie，在这里，“tick”指的是系统定时器运行，而不是表示100纳秒的“Tick”单位。 - CodesInChaos

@CodesInChaos：不，我是指后者。或者至少是四舍五入后的形式，例如49.9纳秒 vs 50纳秒。 - leppie

@RoyiNamir 它确实显示这些数字，但您会发现它们不会单独更改。它们将保持不变，直到毫秒部分发生更改。 - CodesInChaos

Answer 1

`DateTime` 的精度为 100 纳秒。但在典型的实现中，`DateTime.Now` 只会每隔几毫秒才会改变一次。

`Datetime.Now != Datetime.Now` 可能是真的，但这种情况极不可能发生。这是多线程代码中经常出现的典型竞态条件。也就是说，你不应该依赖于 `DateTime.Now` 不会改变，而是要将其存储在本地变量中。

- CodesInChaos

---

它与计算机频率时钟有关吗？ - Royi Namir

这与内部系统计时器有关，会影响到定时器、Thread.Sleep、DateTime.Now、Environment.TickCount、线程切换等。 - CodesInChaos

如果我没记错的话，DateTime.Now 相对较昂贵，因为它使用了 IO。这是存储副本的另一个原因。编辑：这是我所指的链接：https://dev59.com/f2TWa4cB1Zd3GeqPFJ-F - Tim Schmelter

@TimSchmelter 这是因为它需要进行时区转换，所以价格较高。据我所知，实际的时间获取部分相当便宜。在我的计算机上，DateTime.UtcNow 的成本为9ns，而DateTime.Now 的成本为900ns。 - CodesInChaos

Answer 2

DateTime.Now 内部调用：

public static DateTime Now
{
    get
    {
        return DateTime.UtcNow.ToLocalTime();
    }
}

这里涉及内部调用：

public static DateTime UtcNow
{
    get
    {
        long systemTimeAsFileTime = DateTime.GetSystemTimeAsFileTime();
        return new DateTime((ulong)(systemTimeAsFileTime + 504911232000000000L | 4611686018427387904L));
    }
}

在 IT 技术中，GetSystemTimeAsFile 是 WindowsAPI 函数，用于返回 系统 时钟信息。其准确性取决于系统。

如果您在不同时间获取 (DateTime.Now) 之间存在延迟，可能会产生足够不同的结果导致相等比较器失败。但在我的个人经验中，我从未遇到过这种情况。

- Tigran

---

好的，不是很:)如果有人问这样的问题，我只能给出猜测，不知道面前的人会对我有什么看法 :) - Tigran