The HAR spec specifies the startedDateTime of the pages
and entries
objects as:
startedDateTime [string] - Date and time stamp of the request start (ISO 8601 - YYYY-MM-DDThh:mm:ss.sTZD).
The ss.s
portion is a bit ambiguous, but the examples given in the spec go out only to thousandths of seconds. So BrowserMob Proxy only creates entries with thousandths, to avoid breaking HAR readers.
Precision greater than milliseconds is probably going to introduce a lot of additional noise into the timings. Differences in nanoseconds can be caused by all manner of things (such as CPU scheduling) unrelated to the "actual" performance of the HTTP request. Of course that happens with milliseconds as well, but the more precise you get, the less accurate the timings are.
Ultimately, what the startedDateTime really indicates is the time that the system clock reported to some CPU thread spawned by BMP that kicked off at some indeterminate time after the last packet of the HTTP request was received by the network interface, processed by the OS, processed by the JVM, and decoded by netty, which happens asynchronously without timing guarantees. It should only be taken as a "reasonably" close approximation. FWIW, that's the only guarantee Chrome can make, too.