Date general both
The date and time the message was generated — used for caching calculations and request timing.
What it does
Date records when the HTTP message was generated — the timestamp of the response (or request). For responses, it's set by the origin server and used by clients and caches to calculate how old a response is. Combined with Cache-Control: max-age or Expires, Date anchors the freshness window.
Syntax
Date: <http-date>
Always in RFC 7231 HTTP date format — GMT, specific format, no flexibility:
Date: Wed, 21 Oct 2026 07:28:00 GMT
Date: Tue, 15 Nov 2022 12:45:26 GMT
The format is: Day-of-week, DD Mon YYYY HH:MM:SS GMT
Month abbreviations: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
When it's required
Servers must include Date on all responses except:
1xxinformational responses5xxresponses where the clock is unavailable (rare)- When the server genuinely doesn't know the current time
In practice, every response from a real-world server includes Date. Caching infrastructure depends on it — without Date, a cache can't compute how old a response is relative to its max-age or Expires value.
Role in cache freshness
Date is the reference point for cache age calculations:
Response age = Current time - Date value
Remaining freshness = max-age - Response age
Or when Age is present (added by CDNs):
Remaining freshness = max-age - Age
Example:
Date: Wed, 21 Oct 2026 10:00:00 GMT
Cache-Control: max-age=3600
Age: 1800
The response was generated at 10:00. It has a 1-hour freshness window. A CDN has held it for 30 minutes. Remaining freshness: 30 minutes.
Heuristic caching
When Cache-Control and Expires are absent, caches can use Date and Last-Modified together for heuristic caching — a guess at how long to cache the response:
Heuristic max-age ≈ (Date - Last-Modified) × 0.1
If the resource was last modified 10 days before the response date, the heuristic suggests a 1-day freshness. This is a fallback — explicit Cache-Control always takes precedence.
Date on requests
Clients can include Date on requests, but almost never do. It's optional and largely ignored by servers. Some logging systems use it for request timing, but there's no functional reason for clients to set it.
Common mistakes and gotchas
Server clock drift. Date is only as accurate as the server's clock. NTP synchronisation is essential — a server with a clock 10 minutes fast issues responses with future Date values, which can cause caches to miscalculate freshness. Always run NTP on production servers.
Generating Date in the wrong timezone. Date must be GMT. Servers that generate timestamps in local time and forget to convert will produce invalid values. Many frameworks handle this automatically — but custom HTTP implementations often get it wrong.
Relying on Date for precise request timing. Client and server clocks may differ by seconds. If you need precise latency measurement, use application-level timestamps, not HTTP headers.
Real-world examples
Standard response:
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2026 10:00:00 GMT
Content-Type: application/json
Cache-Control: public, max-age=3600
ETag: "abc123"
CDN response with Age:
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2026 10:00:00 GMT
Cache-Control: public, max-age=86400
Age: 43200
Generated at 10:00. CDN has held it for 12 hours (43200 seconds). 12 hours of freshness remaining.
FAQ
Is Date the same as Last-Modified?
No. Date is when the response was generated. Last-Modified is when the resource was last changed. A resource last modified a year ago can have a Date of today — that's normal for cached, rarely-changed resources.
What if there's no Date header?
Technically non-compliant for most responses. Caches that require Date for freshness calculations may treat the response as uncacheable or apply conservative heuristics. Well-configured servers always include it.
Can I use Date for rate limiting or replay protection?
You can reference it, but don't rely on it for security. Clients control the Date on their own requests, and server Date values can drift. For API replay protection, use nonces or short-lived tokens rather than timestamp-based checks.
Fun fact
The HTTP Date format (Wed, 21 Oct 2026 07:28:00 GMT) descends directly from RFC 822 email date format (1982). HTTP borrowed its date format from SMTP, which made sense in the early web when many of the same engineers worked on both protocols. The specific format — day-of-week, day, month-abbreviation, 4-digit year, time, GMT — became a web standard almost by accident, baked in from the first HTTP specification in 1991. It's been unchanged for 35 years despite being verbose and hard to parse compared to ISO 8601.