I'm curious to know whether or not NTPD is going to effect TTL? And now that more granular TTL has been implemented what are the effects of NTPD-based time shifting on the record instances.
Comment From: pietern
TTL is stored as Unix timestamp, computed when the TTL command is executed. This value is compared with the current time according to time(NULL) whenever the key in question is accessed, or Redis is actively trying to evict keys. This means that ntpd shifting time causes keys to expire earlier or later.
Whether this behavior is expected or correct for the TTL command may be up to debate. One thing to keep in mind is that Redis also supports EXPIREAT, which takes an explicit timestamp and therefore should definitely follow the system clock. To support TTL based on wall clock time we would need to keep track of wall clock time and add some kind of flag to the expiry table. We can discuss this some more and see if this is something that adds lots of value.
Thanks for bringing it up!
Comment From: rbucker
That's good info. I'm not suggesting that a code change or design change... just some good old fashioned documentation. Thanks!
*
Richard Bucker * Florida Freelance IT LLC * * * *
On Mon, Nov 28, 2011 at 9:21 PM, Pieter Noordhuis < reply@reply.github.com
wrote:
TTL is stored as Unix timestamp, computed when the TTL command is executed. This value is compared with the current time according to
time(NULL)whenever the key in question is accessed, or Redis is actively trying to evict keys. This means that ntpd shifting time causes keys to expire earlier or later.Whether this behavior is expected or correct for the TTL command may be up to debate. One thing to keep in mind is that Redis also supports EXPIREAT, which takes an explicit timestamp and therefore should definitely follow the system clock. To support TTL based on wall clock time we would need to keep track of wall clock time and add some kind of flag to the expiry table. We can discuss this some more and see if this is something that adds lots of value.
Thanks for bringing it up!
Reply to this email directly or view it on GitHub: https://github.com/antirez/redis/issues/217#issuecomment-2911145
Comment From: pietern
I know, the question just got me thinking :-)
The semantical difference between "time to live" and "at time T" is that you think about relative time with the first, and absolute time with the second. Using wall clock time for "time to live" makes more sense than using absolute time in that line of thought.
Comment From: rbucker
I occurs to me that this will effect the info() as well. Like the LAST_SAVE.
Comment From: yoav-steinberg
I think the documentation added in https://github.com/redis/redis-doc/commit/a2fa910b covers this. I'm closing, took 10 years :)
Comment From: itamarhaber
@yoav-steinberg 🙇