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.
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.
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.
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 everyDocument 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).
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.Instant.now().plus(2, 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.
@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).
