Incorrect cache expiry checks in non-UTC time zones lead to premature cache invalidation

[eypcnckr]

Functional impact

Yes. The bug results in incorrect cache expiration checks when the application runs in a time zone different from UTC, leading to stale or prematurely expired cache entries.

Minimal repro steps

1. Create a web application project targeting .NET Framework 4.6.2.
2. Decorate an endpoint with the OutputCacheAttribute class, using Duration=3600 (1 hour).
3. Ensure the project is running in a time zone that is not UTC (e.g., UTC+3, as in Turkey).
4. Implement caching logic in a class that uses OutputCacheModuleAsync.
5. Make a request to the cached endpoint.

Expected result

The cache entry should remain valid for the full duration of 1 hour (3600 seconds) as specified, regardless of the server's time zone, and the endpoint response should come from the output cache.

Actual result

Cache entries are prematurely invalidated or stale data is served due to incorrect time zone handling, resulting in responses not coming from the output cache.

Further technical details

The root cause is the use of DateTime.Now for comparison instead of DateTime.UtcNow, which leads to incorrect evaluations of cache expiry in applications running in non-UTC time zones (e.g., Turkey UTC+3).

AspNetOutputCache/src/OutputCacheModuleAsync/OutputCacheHelper.cs

Line 1063 in 8c37dd1

if (utcExpires > DateTime.Now) {

The problem is caused by the line above.