Skip to content

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

Closed
@eypcnckr

Description

@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).

if (utcExpires > DateTime.Now) {

The problem is caused by the line above.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions