Hi @linqFR,
First, the use of TTL/expiry can be confusing if it is an absolute unix timestamp it is pretty straightforward in N1QL and most of our SDKs (number of seconds since epoch) is just what you pass it. But you can also pass a fairly small number less than 30 days it is an offset for more details refer to document-expiration. You also need to understand the “precedence” as disclosed in buckets:expiration
Second, although the TTL in always in seconds on the doc (property “expiration” in its metadata) there can be further confusion as in languages like Node (e.g. JavaScript) the native Date construct is in milliseconds and thus it depends on the Language, API and/or SDK used to determine what you need to pass (seconds, or milliseconds, or some date object).
Yes I agree that the above can lead to a bit of a painful learning curve until the concepts are fully understood.
Now for some fun stuff (from the pure Eventing perspective - hey I am the Eventing PM this is my focus) look at the recently updated 6.6 documentation (sorry but the 7.0 beta isn’t quite current WRT Eventing - I will be working on this 7.0 beta docs shortly)
In 6.5.1 and 6.6.0 you could set the TTL (or expiry) in Eventing like this example docControlledSelfExpiry here we drop to N1QL via the N1QL(…) function and update the expiration via a USE KEYS clause. And here we use seconds when we set the TTL.
However starting in 6.6.1 Eventing now supports Advanced Bucket Accessors where you can now directly set the TTL (or expiry) with KV instead of dropping down to a N1QL(…) function as per this example advancedDocControlledSelfExpiry using a basic JavaScript Date object - thus here we are using milliseconds to set the TTL in this instance (and the underlying server code takes care of converting to seconds). This is about 5X faster as it is a pure KV operation.
Best
Jon