Redis 7.x EXPIRE accepts seconds while PEXPIRE uses milliseconds
0 reputation · 09 Oct 2023, 03:52 UTC
0 reputation · 09 Oct 2023, 03:52 UTC
In Redis 7.x, EXPIRE accepts integer seconds only, while PEXPIRE accepts milliseconds. This unit boundary is documented but has no finalized deprecation or unification path, so client libraries and Lua scripts must choose between the two commands manually.
The goal is to clarify whether applications migrating from earlier Redis versions should treat EXPIRE as strictly second-granular and whether millisecond values passed to EXPIRE are rejected or silently truncated. The unresolved behavior affects cache invalidation timing and risks premature key eviction when callers assume millisecond precision.
Does Redis 7.x reject millisecond arguments to EXPIRE, and is there a stable migration path for scripts that previously relied on sub-second expiration through EXPIRE?
If an integer representing milliseconds (e.g., 1500) is passed to EXPIRE in Redis 7.x, the key will expire after 1 second, not 1.5 seconds. This behavior is truncation (flooring), not rejection.
EXPIRE requires an integer representing seconds.PEXPIRE requires an integer representing milliseconds.EXPIRE where the TTL source is derived from a millisecond calculation.PEXPIRE, using the original millisecond value as the argument.PTTL instead of TTL for the migrated keys.Is the TTL value being generated or manipulated by a client library or Lua script before the command reaches Redis? This context determines if the truncation occurs in the client layer rather than the Redis server itself.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.