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 不会更正确和/或更安全？

（是的，我可以仔细阅读来源和/或反射源，但我正在寻找完整的详细内幕！）

Answer 1

我不久前在 Microsoft Connect 上报告了此错误，但它是已关闭，因为无法修复。

如果您指定本地时间的绝对过期时间，那么在 .NET 2.0 中仍然会遇到问题。

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

在欧洲，夏令时于 2009 年 10 月 25 日 02:00 结束。下面的示例说明，如果您在 01:59 将一个项目放入缓存且过期时间为 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 或更高版本的解决方法是指定 UTC 中的绝对过期时间，如 Ruben 指出的那样。

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

编辑

来自评论：

但只有在以下情况下才会发生暴露：
转换发生在重叠期间。
实际进行的单次转换
地点是您提交物品的时间
缓存.添加

仅当您在夏令时结束时的一个不明确的小时内将本地时间的 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。 local=GMT+2，因此 UTC = 2009-10-24 23:59:00

• .AddMinutes(2) = 2009-10-25 02:01:00 本地。 local = 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 ...)

从注释中：

或者我错过了什么？

不，你不是。您的分析是正确的，如果您的应用程序对时间要求严格并且在 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 在他的回答中指出的，当缓存项的添加和过期跨越夏令时结束时，会导致意外行为。

Answer 3

[高度衍生自 Jeff Sternal 的答案，我在不完整的付款中+1:D]

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

因此...

1. 在 1.x 中，如果您 [API 用户] 使用 DateTime.UtcNow （并且在调用期间对 DST 开始很敏感），您最终会陷入混乱Cache.Add)

2. 在 2.0 [和 3.x] 中，只要 Kind 即可安全使用设置您提供的时间[如果您从 DateTime.Now 或 UtcNow 获取时间，通常会是这样]。 [有关完整理由，请参阅 Joe 的评论和回答] 绝对更喜欢 UtcNow 作为 1 小时 DST 切换的歧义。

3. 这个例子保持原样，这样反对 1.x 的人们就不会被误导[人们可以继续假装 DST 是一个古怪的边缘情况 :P]。 [同上，正如 Joe 所指出的] 但这是一个非常有争议的立场，因为这可能会导致内容在缓存中停留额外一个小时。

我仍然很有兴趣听到更多细节，包括来自任何小马的任何细节。

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

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