Expiration value could indicate clearer the two different modes (interval vs timestamp) about memjs HOT 3 OPEN

So, memjs just passes along the value to memcache. There actually isn't a maximum TTL value in memcache. However, anything over 30 days (2592000 seconds) is treated as an absolute epoch time (seconds since Unix 1970). The documentation for Client#create describes this.

All ears if you think there is a good way to reflect this in the API, though!

from memjs.

Could you inspect the TTL, and if over the 30 day limit, return an error if the epoch is in the past (before now)? If you are caching with a TTL, defining an expiry date in the past doesn't make a lot of sense.

from memjs.

That's a possibility. I see a couple issues with that:

1. The semantics of the TTL are to use the clock of the server running memcache, while checking on the client-side would have to use the local clock, which may not be synchronized. So it's not unreasonable that by trying to validate the TTL on the client would result in an incorrect error.
2. The behavior of memcache is not to return an error if the TTL is in the past. This could very well be behavior that a user exploits (for example, to elide a test for the validity of some value when setting it, and just letting memcache do that work).

This seems like an unfortunate choice of the memcache protocol, but a choice we need to live with. This is a command that accepts two types of parameters, that happen to have the same type, without anything in the protocol to differentiate what the caller means (and an arbitrary cutoff point).

I'd be open, instead to adding some type information to commands that accept a TTL to help a user be explicit about their choices. For example, I can imagine the TTL value taking an object that is either an Interval or a Timestamp and converting it to an integer for memcache accordingly. It'd just have to do this in a backwards compatible way...

from memjs.