[
https://issues.apache.org/jira/browse/LOG4J2-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313226#comment-17313226
]
Ralph Goers commented on LOG4J2-3058:
-------------------------------------
As far as I know this is already supported. Log4j's SystemClock class supports
the finer-grained clock supplied by java.time.Instant in Java 11. However, that
comes with a cost as java.time.Instant is not garbage free. There does not
appear to be any other way in the JDK to get anything better than millisecond
granularity without using java.time.Instant. That said, I believe Java still
only supports microsecond granularity, primarily because the hardware clocks
aren't more precise than that, even if they will hold nanoseconds.
> Support UNIX_NANOS in PatternLayout
> -----------------------------------
>
> Key: LOG4J2-3058
> URL: https://issues.apache.org/jira/browse/LOG4J2-3058
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
> Affects Versions: 2.14.1
> Environment: Tested on MacOS 10.15, Java 11.
> Reporter: Andrew Harris
> Priority: Trivial
>
> Hello! I would like to have access to a predefined named format for
> PatternLayout that yields a Unix epoch nanosecond, so that I can more easily
> meet requirements of log processors that ask for Unix epoch nanos. An
> operative example is the [OpenTelemetry log
> format|https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-timestamp]
> which asks for such.
> This predefined format could be called {{UNIX_NANOS}}, to fit with the
> existing {{UNIX_MILLIS}} from LOG4J2-1883. It also looks like the nanosecond
> component could be used directly from
> [Instant|https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/time/Instant.html].
>
> Alternatively, a predefined named format to access an Instant in
> PatternLayout may also work, as one could extract the nano-of-second and
> append that to the {{UNIX}} epoch second.
> As a workaround, the following pattern seems to get close enough to a Unix
> epoch nanosecond. However, I find it a little messy to read, and I'm sure the
> performance could be improved with a dedicated format symbol:
> {noformat}
> %d{UNIX}%replace{%d{HH:mm:ss,nnnnnnnnn}}{^[0-9:]+,}{}{noformat}
> Apologies if there's a duplicate issue for this that I missed. Thank you for
> your consideration!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
