Document expiry in seconds or a timestamp?



I have just seen a strange sentence about document expiry.

On this page:
Document basics

The expiration time starts when the document has been successfully stored on the server, not when the document was created on the application server. Any expiration time larger than 30 days in seconds is considered absolute (as in a Unix time stamp), anything smaller is considered relative in seconds.

It is still true ?
I don’t see in the source code where is this conversion.
I will be boring to compute a new timestamp if i want to keep my document for more than 30 days.

Async expiration update ( Touch ) with over 30 days, is it supported?

Yes this is still true. The SDK doesn’t change currently interpret nor change the expiry value, and this interpretation (absolute vs timestamp) is made on the server side.


But this page make me confused …

See on the important section

Some of the SDKs, most notably the Java and .NET SDKs, provide convenience methods to set the TTL value. These convenience methods handle the translation logic for TTL values under and over 30 days.

Java SDK seems to not do this translation … :’(


Mmmh yeah this is confusing. Even the .NET SDK doesn’t do that with expirations expressed as a uint actually (although it does perform the conversion when you provide a TimeSpan object, which is more explicit in what you want to do).

The problem is that providing a long expiry over the 30 days limit is a valid usage, so we cannot assume the user made a mistake and convert.

Maybe we could add constructor to every Document implementation, one that takes the expiry as a long+TimeUnit pair? Or add a utility method to the SDK to explicitly let the user perform the conversion (so that if you use it in your code, at least it is explicit that you provided a duration in seconds and you want it to become a timestamp if necessary).

@daschl what do you think?


long + TimeUnit seems to be a good evolution.

Actually, in Java SDK, the expiry is a int, an automatic conversion with 2 parameters (long, TimeUnit) seems better.

Do you know what the storage engine use to store the expiration time, an int or a long ?

Or you will encountered this :
bug 2038 :wink:


So here is the thing, even if we fix it on the client, the server still stores it as an int. the binary protocol also uses int for the expiry.

The whole problem will need to be tackled more holistically. Note that recently an issue was raised in JCBC-899 maybe we can discuss it there further.

If we have plenty of demand for the same thing I’m happy to consider doing it, but it will add quite of ambiguity and surface area to the document interface (and keep in mind there are other APIs which take the expiry directly, like touch).


I’m confronted with the same problem.
I would like to generalise on the Unix Time.
With Java 8, I can easily get it, java.time.temporal.ChronoUnit.MINUTES).toEpochMilli() (Expiration 2 min from now)

but this generate a long value and the parameter in the JsonDocument.create method only takes an int.
It should take a long value.

What are the plans regarding this ?



@danieldeluca we’re still looking at this, but if you don’t need to store timestamps that expire later than 2038 you can safely convert to int (maybe range check with Integer max value to be safe).