Node.js Date object’s represent time in milliseconds as opposed to the seconds you receive in a unix timestamp. So in your case, you’re actually looking to do something like this:
> new Date(1597423505 * 1000)
2020-08-14T16:45:05.000Z
then how to set the current timestamp to expiry in one day?
bucket.insert(
id,
{ ...data, ...body },
{ expiry: what to set here to make document expiry in 1 day },
(error) => {
if (error) reject(error);
else resolve({ id });
}
);
For Couchbase SDKs which accept simple integer expiry values (as opposed to a proper date or time object) allow expiration to be specified in two flavors.
As an offset from the current time.
As an absolute Unix time stamp
If the absolute value of the expiry is less than 30 days ( 60 * 60 * 24 * 30 seconds), it is considered an offset . If the value is greater, it is considered an absolute time stamp .
It might be preferable for applications to normalize the expiration value, such as by always converting it to an absolute time stamp. The conversion is performed to avoid issues when the intended offset is larger than 30 days, in which case it is taken to mean a Unix time stamp and, as a result, the document will expire automatically as soon as it is stored.
Just to add to @vsr1’s answer: Node.js deals with dates almost entirely in terms of ‘milliseconds since epoch’, where as standard unix timestamps are ‘seconds since epoch’. So in your case, again you need to perform that conversion:
// Using Dates's directly:
expiry: (new Date()).getTime() / 1000
// Since I saw you are using moment:
expiry: moment().add(40, "days").unix()
Hi Brett, has the option to set absolute unix time been removed?
I have the following code which I use when testing new insertion methods, was working fine before but now the expiry time is always considered an offset in seconds using the last sdk 4.4.5
var duration = { minutes: '1' };
var options = { 'expiry': moment.utc().add(duration).unix() };
It’s quite possible. The server makes assumptions about the expiration based on the size (delta vs absolute), and the SDK tries to compensate. I can look up.the ticket and details if you like.
Jira (JSCBC-124) indicates that the change from Jira (CBD-3509) was not present in the nodejs 4.x SDK until 4.3.1
There is no option to pass an absolute timestamp in the nodejs sdk. There is a request to support it Jira (JSCBC-1270)
Here’s some text from earlier discussion…
if they were passing an expiry in seconds of times greater than 30 days (but not absolute times) - without JSCBC-1245 - the server would treat those as epoch+expiry, resulting in the documents being deleted immediately. With JSCBC-1245, those documents would be deleted at now()+expiry
Also - if they use now() + ttl for the expiry, it looks like the SDK will add another now() - setting the document expiry to the year 2078.
I cannot see CBD-3509, it doesn’t let me access it.
Anyway even without any parameter it was possible to pass absolute time before, my code is almost identical to the one brett posted above and the resulting value is higher than ( 60 * 60 * 24 * 30 seconds), so it should be treated as absolute, but it it is still treated as offset. Either the SDK is doing an unnecessary conversion or the server makes the wrong assumption.
That is correct - it was possible to pass as an absolute time-stamp - that was an error on the SDK. It should not have been able to pass as a timestamp and is no longer possible to pass as a timestamp. If you have a timestamp, subtract now() from it to get a delta time.
Ok, thanks. I will change it, luckily I have few instances of this to revise.
Anyway the other SDK, like the Java one above still mentions the possibility.