Negative response time in Jetty server access log - jetty

Question

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>

Answer 1

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.