Cache.Add绝对过期 - 基于UTC？ [英] Cache.Add absolute expiration - UTC based or not?
问题描述
Cache.Add 使用 DateTime.Now.Add 计算过期时间，即通过：
The examples for Cache.Add uses DateTime.Now.Add to compute the expiration, i.e. it passes:
DateTime.Now.AddSeconds(60)
作为 absoluteExpiration 参数。
我以为计算它相对于 DateTime.UtcNow 将更正确[因为如果夏时制从现在到到期时间之间的间隔时间开始，则没有歧义]。
I'd have thought that computing it relative to DateTime.UtcNow would be more correct [as there is no ambiguity if Daylight Savings Time starts in the intervening time between now and the expiration point].
在引入 DateTimeKind ，我猜测缓存管理中有一些丑陋的黑客，如果时间不是UTC时间，它可以做一些适当的事情。
Before the introduction of DateTimeKind, I'd have guessed that there's some ugly hacks in the cache management to make it do something appropriate if the time was not a UTC time.
在.NET 2.0和更高版本中，我猜想它应该处理一个计算为 DateTime.UtcNow的它有 DateTime 。正确地给出了AddSeconds（60） DateTime.Kind 用作其推论中的输入。
In .NET 2.0 and later, I'm guessing that it should handle a DateTime calculated as DateTime.UtcNow.AddSeconds(60) correctly given that it has DateTime.Kind to use as an input in its inferences.
我一直自信地使用 DateTime.UtcNow 作为多年的基础，但无法提出一个理由，这绝对是正确的事情，没有任何指出，文档已经高度误导4年以上。
I've been confidently using DateTime.UtcNow as the base for years, but wasnt able to come up with a rationale that this is definitely the correct thing to do in the absence of anything pointing out the documentation has been highly misleading for 4+ years.
问题？
- 谷歌搜索我无法从MS找到关于这个的任何权威的讨论 - 任何人都可以找到关于这个的东西？
- 是否有任何理由为什么使用UtcNow不会更正确和/或安全？ （$，
- Despite much bingage and googling I wasnt able to find any authoritative discussion on this from MS - can anyone locate something regarding this?
- Is there any reason why using UtcNow wouldnt be more correct and/or safe?
（是的，我可以仔细阅读来源和/或Reflector的来源，但是正在寻找一个完整的打击下降！）
(Yes, I could peruse the source and/or the Reflector'd source, but am looking for a full blow-by-blow lowdown!)
推荐答案
我在Microsof上报告了这个错误t Connect ，但它已被关闭，因为无法解决。
I reported this bug on Microsoft Connect some time ago, but it's been closed as won't fix.
如果您指定绝对过期时，您仍然在.NET 2.0中出现问题在当地时间。
You still have a problem in .NET 2.0 if you specify your absolute expiration in local time.
在夏令时结束一个小时内，您当地的时间不明确，因此您可以获得意想不到的结果，即绝对到期可以是一个小时超过预期。
During one hour at the end of daylight savings time, your local time is ambiguous, so you can get unexpected results, i.e. the absolute expiration can be one hour longer than expected.
在欧洲，夏令时间在2009年10月25日02:00结束。下面的示例说明，如果您将一个项目放在缓存中01:59过期2分钟，它将保留在缓存中1小时2分钟。
In Europe, daylight savings time ended at 02:00 on 25 October 2009. The sample below illustrates that if you placed an item in the cache at 01:59 with an expiration of 2 minutes, it would remain in the cache for one hour and two minutes.
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。
The workaround for .NET 2.0 or later is to specify the absolute expiration time in UTC as pointed out by Ruben.
Microsoft应该建议在绝对过期的示例中使用UTC，但我猜想有可能会混淆，因为这个建议只适用于.NET 2.0和更高版本。
Microsoft should perhaps be recommending to use UTC in the examples for absolute expiration, but I guess there is the potential for confusion since this recommendation is only valid for .NET 2.0 and later.
编辑
From the comments:
但曝光仅在
转换发生在重叠时发生。
实际使用
的单一转换是当您提交
的项目时Cache.Add
But the exposure only occurs if the conversion happens during the overlap. The single conversion actually taking place is when you lodge the item with Cache.Add
只有在夏令时结束时的一个不明确的时间内，在本地时间内使用AbsoluteExpiration时间插入缓存中的项目才会出现此问题。
The problem will only happen if you insert an item in the cache with an AbsoluteExpiration time in local time during that one ambiguous hour at the end of daylight savings time.
所以例如，如果您当地的时区是中欧（冬季GMT + 1，夏季GMT + 2），并于2009年10月25日01:59:00执行以下代码：
So for example, if your local time zone is Central European (GMT+1 in winter, GMT+2 in summer), and you execute the following code at 01:59:00 on 25 October 2009:
DateTime absoluteExpiration = DateTime.Now.AddMinutes(2);
Cache.Add(... absoluteExpiration ...)
然后项目将保留在缓存1小时2分钟，而不是你通常期望的两分钟。这可能是一些高度时间关键的应用程序（例如股票行情，航空公司出发板）的问题。
then the item will remain in the cache for one hour and two minutes, rather than the two minutes you would normally expect. This can be a problem for some highly time-critical applications (e.g. stock ticker, airline departures board).
这里发生了什么（假设欧洲时间，但原则是任何时区相同）：
What's happening here is (assuming European time, but the principle is the same for any time zone):
-
DateTime.Now = 2009-10-25 01:59:00本地。本地= GMT + 2，所以UTC = 2009-10-24 23:59:00
DateTime.Now = 2009-10-25 01:59:00 local. local=GMT+2, so UTC = 2009-10-24 23:59:00
.AddMinutes（2）= 2009-10-25 02：当地01:00本地= GMT + 1，所以UTC = 2009-11-25 01:01:00
.AddMinutes(2) = 2009-10-25 02:01:00 local. local = GMT+1, so UTC = 2009-11-25 01:01:00
Cache.Add将过期时间内部转换为UTC（2009- 11-25 01:01:00），所以到期时间是当前UTC时间（23:59:00）前一小时二分钟。
Cache.Add internally converts the expiration time to UTC (2009-11-25 01:01:00) so the expiration is one hour and two minutes ahead of the current UTC time (23:59:00).
如果您使用DateTime.UtcNow代替DateTime.Now，缓存到期将为两分钟（.NET 2.0或更高版本）：
If you use DateTime.UtcNow in place of DateTime.Now, the cache expiration will be two minutes (.NET 2.0 or later):
DateTime absoluteExpiration = DateTime.UtcNow.AddMinutes(2);
Cache.Add(... absoluteExpiration ...)
从评论中： / p>
From the comments:
或者我错过了什么？
Or am I missing something?
不你不是。您的分析是现场的，如果您的应用程序是时间紧迫的，并在DST结束时运行，您就可以使用DateTime.UtcNow。
No you're not. Your analysis is spot on and if your application is time-critical and runs during that period at the end of DST, you're right to be using DateTime.UtcNow.
鲁本的回答说：
你可以安全使用，只要你的供应时间设置为
you're safe to use either as long as the Kind on the time you supply is set
不正确。
这篇关于Cache.Add绝对过期 - 基于UTC？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
