Does memcached validate that absolute expiration times are supplied in UTC?
0 reputation · 26 May 2025, 18:27 UTC
Memcached stores expiration values either as a relative offset in seconds or as an absolute Unix timestamp, comparing the stored value against its own system clock. The protocol specification states that absolute times are interpreted as Unix time, but it does not define any timezone conversion or validation mechanism. Because the server clock runs in UTC, a client that supplies an absolute expiration derived from local wall-clock time without conversion may cause items to expire earlier or later than intended. There is currently no documented memcached configuration option to adjust for client time zones or to reject non-UTC absolute timestamps, leaving the responsibility entirely with the client.
Does memcached provide any configuration or protocol extension to validate or reject absolute expiration values that appear to be local wall-clock times rather than UTC Unix timestamps? When a client sends an absolute exptime derived from local time without conversion, does the server treat the value strictly as seconds since the Unix epoch, or are there any conditions under which the interpretation changes? Which documented memcached behaviors or version-specific changes should developers verify to confirm that absolute expirations remain tied to the server's UTC clock across different system timezone settings?