Should we use System.nanoTime() instead of System.currentTimeMillis() for tracking the request time?

[costimuraru]

I noticed Jetty provides a handy method to retrieve Request.getTimeStamp() (the start time for when the request was received). This is very helpful because by giving us access to this timestamp, we can compute QoS metrics (how much time we spent processing the request) and log those in our system (e.g. by using a RequestLog [1]).
I noticed that Jetty uses System.currentTimeMillis() for setting this timestamp, which may be problematic. [2]
For instance, see this from Android:

System.currentTimeMillis() is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can be set by the user or the phone network (see setCurrentTimeMillis(long)), so the time may jump backwards or forwards unpredictably. This clock should only be used when correspondence with real-world dates and times is important, such as in a calendar or alarm clock application. Interval or elapsed time measurements should use a different clock.
[3]

What do you think about using System.nanoTime() instead of System.currentTimeMillis()?

If you're just looking for extremely precise measurements of elapsed time, use System.nanoTime()
[4]

[1] https://stackoverflow.com/questions/33493960/how-to-track-the-http-request-and-response-time-in-jetty
[2] https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannel.java#L632
[3] https://developer.android.com/reference/android/os/SystemClock.html
[4] https://stackoverflow.com/questions/351565/system-currenttimemillis-vs-system-nanotime

[sbordet]

See #121.

The problem is that for certain things you really want the GMT time, not the number that System.nanoTime() returns, because you don't want to compute deltas, but just know the instant in time.

We should also update to java.time, but it's some work.

[stale]

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

[sbordet]

Closing in favor of #121.