Does memcached validate that absolute expiration times are supplied in UTC?

Answer

Memcached does not validate that absolute expiration values are supplied in UTC. It simply interprets any integer greater than 2,592,000 (30 days) as a literal Unix epoch timestamp and compares that value against the server’s own system clock. No protocol extension or configuration option exists to reject or convert non‑UTC timestamps.

How memcached interprets the value

• Relative mode – if exptime <= 2,592,000 (30 days), the value is treated as a relative offset in seconds from the current time.
• Absolute mode – if exptime > 2,592,000, the value is treated as a Unix epoch timestamp (seconds since 1970‑01‑01 UTC).
• The comparison is made against the server’s local clock; if the host OS is set to a non‑UTC timezone, the epoch seconds are still interpreted as UTC, but the server’s clock may be off relative to true UTC.

No built‑in validation or rejection

There is no documented memcached configuration option that enforces UTC or rejects apparent local‑time expirations. The responsibility to supply a correct UTC timestamp lies entirely with the client. If a client mistakenly sends a local wall‑clock value without converting to UTC, the item will expire at the wrong instant, silently.

What to verify

• Confirm that the memcached server’s host time is set to UTC (e.g., timedatectl status on Linux). The server uses this clock for all expiration calculations.
• Check the memcached version you are running (e.g., memcached -V). All released versions up to the latest stable release exhibit the same 30‑day threshold behavior.
• Verify that your client library converts local times to UTC before sending absolute expirations. Many libraries expose a helper or configuration flag for this purpose.

Practical test

To confirm the interpretation, you can store a key with an absolute expiration derived from your local time, then observe when it expires. For example, on a machine set to UTC‑5:

# Compute an absolute expiration 1 hour from now (local time)
exp=$(date -u -d '1 hour' +%s)
# Store the key with that expiration
printf 'set mykey 0 0 %d\r\nvalue\r\n' $exp | nc localhost 11211
# Wait 1 hour and check that the key is gone
# (or use a shorter offset to observe earlier/later behavior)

If the server clock is off by the timezone offset, the key will expire earlier or later than expected, illustrating that no conversion occurs on the server side.

Version consistency

Across all documented memcached protocol releases, the 30‑day threshold and the lack of timezone validation have remained unchanged. No version‑specific change alters how absolute expirations are tied to the server’s UTC clock.

Follow‑up

To avoid unintended expirations, ensure that:

• The server’s system clock is synchronized to UTC (e.g., via NTP or systemd‑timesync).
• Your client code explicitly converts local wall‑clock times to UTC before sending absolute expirations.
• You test with a known local offset to confirm the server’s interpretation matches expectations.

If you still observe discrepancies, double‑check the server’s date output and verify that the memcached process is running with the same timezone settings.