Alfred, Sub-milli time stamps have been implemented and will be in the next release. Note that this uses standard Java APIs and will only work on Java 9 and higher. The next release is feature complete and will come out as soon as the release manager has time to do the work.
As Gary pointed out, you can try this now with a SNAPSHOT release. I couldn’t find a link to the SNAPSHOT releases on the site, but the README in git has a link: https://logging.apache.org/log4j/2.x/maven-artifacts.html#Snapshot_builds We should add this link to the main site. (Shameless plug) Every java main() method deserves http://picocli.info > On Feb 11, 2018, at 6:22, Gary Gregory <[email protected]> wrote: > > Why not give a SNAPSHOT build a go? > > Gary > >> On Feb 10, 2018 14:14, <[email protected]> wrote: >> >> Thank you for the pointer, Ralph. Glad to see there's good progress on >> this. >> >> In the meantime I guess I'll have to stick with my current approach, >> except I'll change it to (ab)use NanoClock/nanoTime field instead. >> >> Cheers, >> Al. >> >> Sent: Saturday, February 10, 2018 at 2:16 PM >> From: "Ralph Goers" <[email protected]> >> To: "Log4J Users List" <[email protected]> >> Subject: Re: Best approach for sub-millisecond timestamps? >> >>> See https://issues.apache.org/jira/browse/LOG4J2-1883 >>> <https://issues.apache.org/jira/browse/LOG4J2-1883> >>> >>> Ralph >>> >>>> On Feb 10, 2018, at 10:42 AM, [email protected] wrote: >>>> >>>> Hello list, >>>> >>>> I need to get more granular timestamps in my logs. >>>> >>>> The question is what is the best way get Log4j to handle >>>> sub-millisecond timestamps? >>>> >>>> A top search result provides this deceptively-simple approach: >>>> http://blog.caplin.com/2017/10/13/microsecond-time-stamp- >> logging-for-mifid-ii/ >>>> >>>> However, that will provide wrong results, since they're generating the >>>> timestamp inside the Converter, which would run in the AsyncLogger >>>> thread and in effect log when the event was processed rather than when >>>> it actually occurred. >>>> >>>> The hack I came up with is to implement a custom Clock whose >>>> currentTimeMillis() returns nanoseconds since the epoch, and a >>>> corresponding Converter plugin that handles nanoseconds in the >>>> millisecond field (Hopefully it won't still be around by year 2262 :) >>>> It works pretty well for what I'm doing so long as both the custom >>>> clock and a correct layout are used, but I imagine it could cause >>>> unexpected consequences if some time-related functionality is used >>>> (e.g. file rolling). >>>> >>>> Any suggestions for a cleaner but low-overhead approach? >>>> >>>> Cheers, Al. >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
