Precisely. On Fri, 16 Apr 2021, 18:35 Ralph Goers <ralph.go...@dslextreme.com> wrote:
> If I am reading that write you are only handling millis. You probably want > to be using an Instant. > > Ralph > > > On Apr 16, 2021, at 9:06 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> > wrote: > > > > Thanks, Ralph! Apparently I need to create a bug report here: > > > > formatResolverContext.calendar.setTimeInMillis(timestampMillis); > > formatResolverContext.timestampFormat.format( > > formatResolverContext.calendar, > > formatResolverContext.formattedTimestampBuilder); > > > > > > On Fri, Apr 16, 2021 at 6:00 PM Ralph Goers <ralph.go...@dslextreme.com> > > wrote: > > > >> Something is definitely odd here. We use FastDateFormat in the > >> DatePatternConverter that is used to print timestamps in the log. It > most > >> definitely displays milliseconds while yours are all 0. I don’t know > that I > >> have ever tried it with more than 3 though. > >> > >> Are you calling > >> > >> void formatToBuffer(final Instant instant, final StringBuilder > destination) > >> That method appears to be the only one that has a granularity smaller > than > >> a millisecond. > >> > >> Ralph > >> > >>> On Apr 16, 2021, at 7:08 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> > >> wrote: > >>> > >>> A JsonTemplateLayout user has reported > >>> < > >> > https://issues.apache.org/jira/browse/LOG4J2-3073?focusedCommentId=17323825&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17323825 > >>> > >>> that the following JSON template > >>> > >>> { > >>> "@timestamp_nano1": { > >>> "$resolver": "timestamp", > >>> "pattern": { > >>> "format": "yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z'", > >>> "timeZone": "UTC" > >>> } > >>> } > >>> > >>> resolves to > >>> > >>> { > >>> "@timestamp_nano1": "2021-04-16T13:09:16.000000008Z" > >>> } > >>> > >>> Internally, processing is performed by TimestampResolver in JTL module, > >>> which utilizes FastDateFormat. Does anybody have an idea about the > >> missing > >>> precision? > >> > >> > > >
