[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092087#comment-16092087
]
Anthony Maire commented on LOG4J2-1883:
---------------------------------------
[~_chandra] : You're perfectly right about the accuracy of such timestamps. You
need specific hardware to have reliable timestamps. Basically NTP is reliable
only to roughly millisecond accuracy so you can have some clock adjustments for
several hundreds of µs. If you need a stable sub-milli accuracy, you will
probably need some PTP capable hardware on your production system (which can
achieve sub-micro accuracy). However I don't see the point here. I think that
it is pretty clear that the sub-milli accuracy is clearly a niche requirement,
for most systems, millisecond accuracy is enough.
About the possibility you pointed earlier to have a backport of this in java 8,
I think it is very unlikely to happen: this is not a very common need, and it
has led to an API change : https://bugs.openjdk.java.net/browse/JDK-8071919
[~jvz] : On a pre-java 9 hotspot/openJDK, you effectively need some native call
to get access to a sub-milli clock from the OS. In our specific need, since we
are using linux in production but most of the developers are using windows, the
simplest way to have such a clock is to use the JNR-POSIX library: it allows
access to the gettimeofday call (microsecond resolution on POSIX compliant OS),
and have a default implementation for windows based on
System.currentTimeMillis(). However it has clearly a performance impact (~150ns
per call instead of ~20ns for System.currentTimeMillis()), that is the price to
pay to avoid the burden to have some real native code in your codebase with
some optimised JNI code.
[[email protected]] : basically, when using a long to store
nanosecond from epoch, you can encode timestamp up to year 2262. If not
supporting later timestamps is OK, it is probably the simplest way to store a
precise timestamp in the LogEvent. That is what I intend to do in a fork that
will fulfill our need (using the "nanotime" field of LogEvent), with some
additional layout converters to format this data.
> Timestamp does not seem to support microseconds level
> -----------------------------------------------------
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
> Reporter: Madhava Dass
> Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <Configuration status="WARN">
> <Appenders>
> <Console name="Console" target="SYSTEM_OUT">
> <PatternLayout
> pattern="[%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
> </Console>
> </Appenders>
> <Loggers>
> <Root level="DEBUG">
> <AppenderRef ref="Console"/>
> </Root>
> </Loggers>
> </Configuration>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: - <message>
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: - <message>
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
