Cache.Add 绝对过期 - 是否基于 UTC？

Question

Cache.Add 的示例使用DateTime.Now.Add 来计算过期时间，即它通过了：

 DateTime.Now.AddSeconds(60)

作为absoluteExpiration 参数的值。

我认为相对于DateTime.UtcNow 计算它会更正确 [因为如果夏令时在从现在到到期点之间的时间开始，则没有歧义]。

在引入DateTimeKind 之前，我已经猜到缓存管理中有一些丑陋的黑客可以让它在时间不是UTC 时间时做一些适当的事情。

在 .NET 2.0 及更高版本中，我猜它应该正确处理计算为 DateTime.UtcNow.AddSeconds(60) 的 DateTime，因为它有 DateTime.Kind 用作推理中的输入。

多年来，我一直自信地使用DateTime.UtcNow 作为基础，但无法提出理由证明这绝对是正确的做法，因为没有任何内容指出该文档对4 年以上。

问题？

1. 尽管进行了大量的狂欢和谷歌搜索，但我无法从 MS 中找到任何关于此的权威讨论 - 任何人都可以找到有关此的内容吗？
2. 为什么使用 UtcNow 不会更正确和/或更安全？

（是的，我可以仔细阅读来源和/或 Reflector 的来源，但我正在寻找一个完整的详细介绍！）

Answer 1

我前段时间reported this bug on Microsoft Connect，但由于无法修复而已关闭。

如果您在本地时间指定绝对过期时间，在 .NET 2.0 中仍然存在问题。

在夏令时结束后的一小时内，您的当地时间是不明确的，因此您可能会得到意想不到的结果，即绝对到期时间可能比预期的时间长一小时。

在欧洲，夏令时于 2009 年 10 月 25 日 02:00 结束。下面的示例说明，如果您在 01:59 将项目放入缓存中并过期 2 分钟，它将在缓存中保留 2 分钟。一小时两分钟。

DateTime startTime = new DateTime(2009, 10, 25, 1, 59,0);
DateTime endTime = startTime.AddMinutes(2);
// end time is two minutes after start time

DateTime startUtcTime = startTime.ToUniversalTime();
DateTime endUtcTime = endTime.ToUniversalTime();
// end UTC time is one hour and two minutes after start UTC time

Console.WriteLine("Start UTC time = " + startUtcTime.ToString());
Console.WriteLine("End UTC time = " + endUtcTime.ToString());

.NET 2.0 或更高版本的解决方法是按照 Ruben 指出的那样以 UTC 指定绝对过期时间。

Microsoft 可能会建议在示例中使用 UTC 来表示绝对过期，但我想这可能会造成混淆，因为此建议仅对 .NET 2.0 及更高版本有效。

编辑

来自cmets：

但只有在 转换发生在重叠期间。 实际占用的单次转换 地点是您提交物品的时间 缓存.添加

仅当您在夏令时结束时的一个模糊小时内将具有 AbsoluteExpiration 时间的项目插入缓存中时，才会出现此问题。

例如，如果您的本地时区是中欧（冬季 GMT+1，夏季 GMT+2），并且您在 2009 年 10 月 25 日 01:59:00 执行以下代码：

DateTime absoluteExpiration = DateTime.Now.AddMinutes(2);
Cache.Add(... absoluteExpiration ...)

那么该项目将在缓存中保留一小时两分钟，而不是您通常期望的两分钟。这对于一些对时间要求非常严格的应用程序（例如股票行情、航空公司出发板）来说可能是个问题。

这里发生的事情是（假设欧洲时间，但任何时区的原则都是相同的）：

• DateTime.Now = 2009-10-25 01:59:00 本地。 local=GMT+2，所以 UTC = 2009-10-24 23:59:00

• .AddMinutes(2) = 2009-10-25 02:01:00 本地。本地 = GMT+1，所以 UTC = 2009-11-25 01:01:00

• Cache.Add 在内部将过期时间转换为 UTC (2009-11-25 01:01:00)，因此过期时间比当前 UTC 时间 (23:59:00) 提前一小时两分钟.

如果您使用 DateTime.UtcNow 代替 DateTime.Now，则缓存到期时间为两分钟（.NET 2.0 或更高版本）：

DateTime absoluteExpiration = DateTime.UtcNow.AddMinutes(2);
Cache.Add(... absoluteExpiration ...)

来自cmets：

还是我错过了什么？

不，你不是。您的分析是正确的，如果您的应用程序对时间要求严格，并且在 DST 结束时的这段时间内运行，那么您使用 DateTime.UtcNow 是正确的。

鲁本回答中的陈述：

只要设置了您提供的时间的种类，您就可以安全使用

不正确。

Answer 2

Cache.Add 将过期日期转换为 UTC，然后再存储。

来自 Reflector（为了便于阅读，我省略了大部分参数）：

public object Add(... DateTime absoluteExpiration ...)
{
    DateTime utcAbsoluteExpiration = DateTimeUtil.ConvertToUniversalTime(absoluteExpiration);
    return this._cacheInternal.DoInsert(... utcAbsoluteExpiration ...);
}

在CacheExpires.FlushExpiredItems 中，utcAbsoluteExpiration 与DateTime.UtcNow 进行比较。正如Joe notes in his answer，当缓存项的添加和过期跨越夏令时结束时，这会导致意外行为。

Answer 3

[从 Jeff Sternal 的回答中高度衍生的见解，我在不完整的付款中 +1 了：D]

似乎在 1.1 中（没有查看 1.0，但我认为它相似），在没有 DateTime.Kind 并且发布了具有 DateTime.Now 相对时间的示例的情况下，他们立即调用 ToUniversalTime() 感到很舒服.

因此...

1. 在 1.x 中，如果您 [API 用户] 使用 DateTime.UtcNow（并且在调用 Cache.Add 期间开始对 DST 敏感），您最终会一团糟

2. 在 2.0 [和 3.x] 中，只要在您提供的时间上设置了 Kind，您就可以安全使用 [如果您从 @987654327 获得时间，通常是这样@ 或 UtcNow]。 [查看 Joe 的 cmets 并回答完整的理由] 绝对更喜欢 UtcNow 作为 1 小时 DST 切换的模糊性。

3. 该示例保持原样，因此使用 1.x 的人不会被误导 [人们可以继续假装 DST 是一个古怪的边缘情况 :P]。 [同上，正如 Joe 指出的那样] 但这是一个非常值得商榷的立场，因为这可能会导致内容在缓存中多停留一个小时。

我仍然很想知道更多细节，包括来自任何小马的任何细节。

编辑：我从 Joe 的 cmets 中意识到，我没有明确指出如果使用 2.0 或更高版本，则使用 UtcNow 肯定更正确更正确，因为一个人面临风险在 DST“土拨鼠时间”期间，该项目被额外缓存一小时。我还认为 MS 文档应该指出这一事实（附带条件是他们需要提及这不适用于 1.1 [无论页面是否标记为 2.0+ 特定]。谢谢乔。

编辑：Noda Time 将有一个简洁的包装来使这个万无一失：D