[ 
https://issues.apache.org/jira/browse/LOG4J2-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315269#comment-17315269
 ] 

Ralph Goers commented on LOG4J2-3058:
-------------------------------------

[~andrew.harris] Thanks. You are correct that there is no easy way around the 
situation. I am communicating with the OpenJDK team to see if something can be 
done but I have my doubts that it would be back-ported to Java 11. At this 
point it would be lucky to make Java 17.

> 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)

Reply via email to