.net – Cache.Add绝对到期 – 是否基于UTC？

DateTime.Now.AddSeconds(60)

我 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中的绝对到期时间。

微软应该建议使用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。 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。

Ruben的回答中的陈述：

是不正确的。