ERROR response for negative expiration values in memcached's set command

Memcached's protocol parser rejects negative expiration integers with an ERROR response, but the server performs no time-zone conversion for absolute expiration timestamps. When an expiration value exceeds REALTIME_MAXDELTA (30 days), memcached interprets it as a Unix timestamp expressed in UTC seconds since the epoch.

A client that calculates this timestamp from a regional local time without converting to UTC may supply a value that is already in the past relative to the server's UTC clock, causing the item to be treated as expired immediately. This creates a gap between explicit validation and silent failure: negative values produce a clear protocol error, while time-zone miscalculations produce no error at all.

The server stores expiration as a 32-bit unsigned integer, and behavior for oversized values can differ between 32-bit and 64-bit builds, adding further uncertainty for clients that derive timestamps dynamically. Given that memcached delegates all time-zone responsibility to the client, what is the correct boundary between client-side UTC normalization and server-side validation? Should clients treat past absolute timestamps as a configuration error to detect before issuing the command, or is there a server-side mechanism to surface this condition? How do 32-bit versus 64-bit builds affect the safe upper bound for client-generated expiration timestamps?