Hrtime vs date.now()

Developing Nodes
1

Hi folks,

In one of my contributions I'm using the hrTime (similar to e.g. the delay-node):

var timestamp1 = process.hrtime();

On the other hand there is also the (less accurate) way to get the the current timestamp (similar to e.g. the inject-node):

var timestamp2 = Date.now();

Now I simply want to convert the timestamp1 to a value identical to timestamp2, but I cannot get identical results (and not even close :woozy_face:). I assume there will be an easy solution, but Google wasn't my ally this time...

Thanks !!
Bart

2

From the Node.JS docs:

These times are relative to an arbitrary time in the past, and not related to the time of day and therefore not subject to clock drift. The primary use is for measuring performance between intervals

It is not intended to use hrtime as an absolute time. Rather it is designed to measure elapsed time.

3

To quote from the spec of hrtime [1]
"These times are relative to an arbitrary time in the past, and not related to the time of day and therefore not subject to clock drift. The primary use is for measuring performance between intervals"
So for hrtime the value 0 is a time in the past but is not any particular time. Generally I think it starts from around boot time but you can't rely on that. Therefore there is no way of getting the real time from it.

[1] https://nodejs.org/api/process.html#process_process_hrtime_time

4

Thanks guys,
I indeed use it in my node-red-contrib-interval-length node to - you might already guess - calculate interval lenghts... So then I will need to create a mix of both solutions.

Have a nice sunday!
Bart

5

Given the vagaries of async callbacks, event loops/stacks, I'd be surprised if the accuracy of hrtime() is better than the milliseconds of Date.now() over the duration of a typical interval loop. (especially when it comes to repeatability)

6

I understand what you're getting at, but its worth saying both hrtime and Date.now() are accurate at the point they are called - with hrtime giving a much higher level of precision.

That is entirely separate to using something like setTimeout where the timeout you give should be considered only as a minimum interval and not a guaranteed exact interval for when the timeout will occur. In fact, you'd use hrtime in a setTimeout callback to calculate very accurately how much time has ellapsed since it was last called, thereby allowing you to account for the inaccuracies the event loop causes.

7

Indeed that is a new feature someone requested last night. My node calculates the interval length between successive messages (based on the hrtimes), or it can generate a timeout message e.g. after 1000 milliseconds (in case no new message arrives within that time interval). As an extra option, that timeout message can be repeated: e.g. when no messages arrives I keep generating timeout messages with 1000 msec in between.

But like you say, it is MINIMUM 1000 msecs in between, which became clear this afternoon when using the hrtime within the setInterval callback function. It is always a bit more as 1000 msecs:

image

But I know enough for now... Thanks all for the fast feedback!!