Use PEXPIREAT to schedule a key for automatic deletion at a fixed point in time, given as a Unix timestamp in milliseconds.
It combines the absolute deadline of EXPIREAT with the millisecond precision of PEXPIRE, which is what you need when many keys must expire at exactly the same instant. A timestamp in the past deletes the key right away.
The optional condition works as elsewhere: NX only when the key has no expiration, XX only when it already has one, GT only when the new deadline is later than the current one, and LT only when it is earlier.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<key> | Yes | No | Redis key targeted by the command. |
<unix-time-milliseconds> | Yes | No | Expiration time as a Unix timestamp in milliseconds. |
(NX | XX | GT | LT) | No | No | Choose one form: NX (only when the key has no expiration); XX (only when the key already has one); GT (only when the new expiration is later than the current one); LT (only when it is earlier). |
Important points#
NXcannot be combined withXX,GT, orLT, andGTandLTcannot be used together.- A key with no expiration counts as an infinite one, so
GTnever sets an expiration on such a key andLTalways does.
Response#
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.
| Protocol | Reply |
|---|---|
| RESP2 | Integer: 1 if the timeout was set, 0 otherwise |
| RESP3 | Integer: 1 if the timeout was set, 0 otherwise |
Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples#
TCP examples use the TLS REDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.