Oops, for some reason I misread that link. It’s on the site already. Good.
On Sun, Feb 11, 2018 at 10:11 Remko Popma <remko.po...@gmail.com> wrote: > 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 <garydgreg...@gmail.com> wrote: > > Why not give a SNAPSHOT build a go? > > Gary > > On Feb 10, 2018 14:14, <alfred.eckm...@gmx.com> 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" <ralph.go...@dslextreme.com> > > To: "Log4J Users List" <log4j-user@logging.apache.org> > > 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, alfred.eckm...@gmx.com 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: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > >
