If your network is air gapped from the Internet then sure. If it's not, you can run NTP against a reasonably reliable set of time sources (not random picks from Pool) and be able to say, "my log timestamps are accurate to +/- 10 milliseconds so it must be you who is farked up." While my milliseconds loses the pecking order contest, it's just as good for practical purposes and a whole lot less expensive.
You mean something like this, which is relatively easy to achieve: ============================================================================== offset -0.000009, frequency -0.823, time_const 30, watchdog 238 synchronised to NTP server (192.5.41.40) at stratum 2 time correct to within 12 ms polling server every 1024 s ============================================================================== remote refid st t when poll reach delay offset jitter ============================================================================== +clock.sjc.he.ne .CDMA. 1 u 287 1024 377 64.313 0.337 0.867 -tock.usnogps.na .IRIG. 1 u 5 1024 377 103.080 -2.097 0.316 -tick.usnogps.na .IRIG. 1 u 806 1024 377 103.053 -2.328 0.363 +india.colorado. .NIST. 1 u 270 1024 377 41.214 -0.159 0.113 +time-b-b.nist.g .NIST. 1 u 984 1024 377 42.609 0.200 0.045 +time-c-b.nist.g .NIST. 1 u 180 1024 377 42.563 0.201 0.064 +time-a-b.nist.g .NIST. 1 u 163 1024 377 42.639 0.137 0.032 *192.5.41.40 .PTP. 1 u 235 1024 377 12.756 -0.388 12.479 -192.5.41.41 .IRIG. 1 u 312 1024 377 13.575 -1.172 2.425 LOCAL(0) .LOCL. 10 l - 64 0 0.000 0.000 0.000 ------------------------------------------------------------------------------ pll offset: -8.474e-06 s pll frequency: -0.823 ppm maximum error: 0.123149 s estimated error: 0.000122 s status: 2001 pll nano pll time constant: 10 precision: 1e-09 s frequency tolerance: 500 ppm ============================================================================== --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.