Use doubles for startTime and endTime

[jaredp]

don’t lose precision by doing integer arithmetic

[jaredp]

It looks like the resolution of the timer is a factor of 10 less granular exclusively on node.js v12 in 64-bit. Does anyone know why?

[3y3]

Hello, @jaredp , thank you for contribution.
I need some time to test this on compatibility with DevTools frontend in node-inspector.
About test - it is very speculative. Testing in cloud containers like Travis and Appveyor can't guaranty what this async operation will be finished in time below 3*delay.
I prefer to see here only least checker.

[jaredp]

Hi @3y3, thanks for taking a look.
The test failed because profiler reported 1.5469829999999547 seconds for what should have been a delay of 0.15 seconds. We should expect on a box that's not too busy to see an elapsed time a little over 0.15 seconds but likely less than 0.16 seconds; 0.15469... seconds would be perfectly expected. On an AppVeyor box busy with other things, we can expect to see an elapsed time a coefficient more, but this is exactly an order of magnitude, so I think the reporting is accurate, and for some reason the resolution is different in this particular config.

[3y3]

@jaredp , 1.5469829999999547 is a real timeout for this case. In other words iteration on AppVeyor and on Travis can be very slow sometimes. We can't expect what elapsed time will be in interval 150ms < elapsedTime < 160ms. We also can't expect 150ms < elapsedTime < 150h.
I prefer to merge this change without new test.

[jaredp]

Okay, removed the < 350ms test

[jaredp]

ping

[jaredp]

bump