Cache.Add absolute expiration - UTC based or not?

Viewed 10195

The examples for Cache.Add uses DateTime.Now.Add to compute the expiration, i.e. it passes:

 DateTime.Now.AddSeconds(60)

as the value of the absoluteExpiration parameter.

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].

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.

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.

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.

The questions?

  1. Despite much bingage and googling I wasnt able to find any authoritative discussion on this from MS - can anyone locate something regarding this?
  2. Is there any reason why using UtcNow wouldnt be more correct and/or safe?

(Yes, I could peruse the source and/or the Reflector'd source, but am looking for a full blow-by-blow lowdown!)

3 Answers
Related