Negative response time in Jetty server access log

I'm running on Jetty and my access log is configured to show the response time.

today I noticed that a very minimal amount of the requests (about 30 out of 600K) have a negative response time and I was wondering if anyone ever encountered such a behavior.

This is a sample of my response: <[IP]> - - <[date]> "POST <[url]> HTTP/1.0" 201 461 -18096

In case you want to identify this in the access log - this is the grep command i used:

grep --color "-[0-9][0-9]*" server-access.2013_12_09.log

Jetty Version: 8.1.8

Setup in jetty.xml:

<New id="request-log-handler" class="org.eclipse.jetty.server.handler.RequestLogHandler">
<Set name="requestLog">
  <New class="org.eclipse.jetty.server.NCSARequestLog">
    <Arg>
      <Property name="logging.httpAccessLog" default="logs/app-access.yyyy_mm_dd.log" />
    </Arg>
    <Set name="retainDays">
      <Property name="logging.accessLogRetentionInDays" default="10" />
    </Set>
    <Set name="append">
      <Property name="logging.httpAccessLogAppend" default="true" />
    </Set>
    <!-- logs referer and user agent -->
    <Set name="extended">
      <Property name="logging.httpAccessLogExtended" default="false" />
    </Set>
    <!-- response time -->
    <Set name="logLatency">
      <Property name="logging.httpAccessLogLatency" default="true" />
    </Set>
  </New>
</Set>

Using Jetty 9.1.0.

Key:

<name> = optional / configurable entry on line
{name} = mandatory entry

<servername> {X-Forwarded-For||remote-addr} - {authentication/principal/name} [{request-timestamp}] "{method} {uri} {protocol}" {response-status-code} {response-content-length} <extended-log> <cookies> <latency>

Where:

<servername> can be the request/Host header
<extended-log> can be "{referer} {user-agent}"
<cookies> can be " -" or "{cookie.name}={cookie-value};"
<latency> can be (now - request.getTimeStamp())

Interestingly, it appears that your system clock adjusted during a request. A full 18 seconds!

Here's why this is the leading theory ...

The request.timestamp is set when the request starts, then the latency is computed later during the access/request logging. For there to be a negative value, either something outside of Jetty itself reset the request.timeout, or the system clock changed.