In the 2.x SDK the expiry was set as either an offset from the current time (if less than 30 days) or an absolute unix timestamp. In the 3.x SDK you need to pass in a Java Duration object to specify the expiry.
I’m wondering if there is a bug here as when we set a duration of greater than 30 days the documents do not appear in Couchbase. We are trying to set an expiry of 90 days. Looking at the SDK code it looks like the Duration is just converted to seconds and passed through so I am assuming that a value of 90 days is then treated as a unix timestamp which is in the past and the document is expired immediately.
How are we able to set longer expiration times with the 3.x SDK? Am I missing something?
Thanks
Craig
Hi @cbensemann
First, let me explain some of the background on why it’s a Duration now rather than an absolute timestamp: 3.x gave us the opportunity to move to Java 8, and we wanted to express expiry using the Java 8 time values rather than a raw int. Duration was good for expressing the “less than 30 days” part of expiry… however, it wasn’t a great match for the “absolute epoch timestamp” part, which would be better expressed as an Instant. The most correct API probably was Either<Duration, Instant>, but we felt that was too clunky. We made the call that the majority of expiry use-cases are likely to be less than 30 days (e.g., for caching use-cases), and optimised the API to express that, with a Duration.
As you’ve seen, the Duration is simply passed down to the server with ‘.asSeconds()’, so it’s still possible to express the absolute timestamp, by creating a Duration that’s has the same number of seconds as the timestamp. (Let me know if that wasn’t clear and I’ll provide some code.)
Hi @graham.pople,
Thanks for the reply and sorry about my slow response.
Your comment does make complete sense. We can just make really large Duration objects. I didn’t even think about doing that 
I guess I had assumed that the SDK would do the translation for me. i.e if less than 30 days just pass through otherwise add on the current timestamp and pass that through. It would be simple enough for it to do and make the API consistent for the user. Regardless it would be great to have this documented somewhere to help others not get caught out.
Its interesting you assumed less than 30 days would be the normal use case. While I can totally understand that I think we are almost exclusively using expiry times larger than 30 - the one I was trying to set here was 90 for example. I don’t think we go over 100 for any records.
Thanks for your help
Craig
HI Graham, i don’t think so, creating Duration of as many seconds as the timestamp works.
It has been observed, that the expiry randomly points to some 19 days, if duration is created in such a way.
Duration i believe is only applicable for a relative expiry of not greater than 30 days(2592000 seconds). For anything with absolute epoch time, Duration just does not work.