You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2021/05/07 15:13:56 UTC
LOG4J2-3075 Formatting timestamps with nanosecond precision
Hello,
I am trying to tackle LOG4J2-3075
<https://issues.apache.org/jira/browse/LOG4J2-3075> reporting that
JsonTemplateLayout doesn't format nanoseconds. I have done some preliminary
study and checked *DatePatternConverter* for inspiration. In a nutshell,
this is what *DataPatternConverter* does:
private Formatter createFormatter(final String[] options) {
final FixedDateFormat fixedDateFormat =
FixedDateFormat.createIfSupported(options);
if (fixedDateFormat != null) {
return createFixedFormatter(fixedDateFormat);
}
return createNonFixedFormatter(options);
}
If *FixedDateFormat* supports the user pattern, it uses the
*FixedDateFormat*, otherwise it falls back to *FastDateFormat*. Here comes
the tricky part... *FixedDateFormat#formatInstant()* supports nanoseconds
passed in by the Log4j *Instant* argument. Though *FastDateFormat* doesn't
format nanoseconds at all. Hence, if the user pattern is not supported by
the *FixedDateFormat*, the fallback *FastDateFormat* doesn't support
nanoseconds. The solution I have in mind is to extend *FastDateFormat* to
support nanoseconds. This is not easy either: *FastDateFormat* accepts Java
*Calendar*, which doesn't support. The not-so-good-but-okayish solution is
to add a similar *#formatInstant()* method to *FastDateFormat*. What do you
think?
Kind regards.
Re: LOG4J2-3075 Formatting timestamps with nanosecond precision
Posted by Matt Sicker <bo...@gmail.com>.
Do note that the FastDateFormat et al. classes are copied directly
from Apache Commons. Most changes done there are relevant to upstream.
:)
On Fri, 7 May 2021 at 10:14, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> Hello,
>
> I am trying to tackle LOG4J2-3075
> <https://issues.apache.org/jira/browse/LOG4J2-3075> reporting that
> JsonTemplateLayout doesn't format nanoseconds. I have done some preliminary
> study and checked *DatePatternConverter* for inspiration. In a nutshell,
> this is what *DataPatternConverter* does:
>
> private Formatter createFormatter(final String[] options) {
> final FixedDateFormat fixedDateFormat =
> FixedDateFormat.createIfSupported(options);
> if (fixedDateFormat != null) {
> return createFixedFormatter(fixedDateFormat);
> }
> return createNonFixedFormatter(options);
> }
>
> If *FixedDateFormat* supports the user pattern, it uses the
> *FixedDateFormat*, otherwise it falls back to *FastDateFormat*. Here comes
> the tricky part... *FixedDateFormat#formatInstant()* supports nanoseconds
> passed in by the Log4j *Instant* argument. Though *FastDateFormat* doesn't
> format nanoseconds at all. Hence, if the user pattern is not supported by
> the *FixedDateFormat*, the fallback *FastDateFormat* doesn't support
> nanoseconds. The solution I have in mind is to extend *FastDateFormat* to
> support nanoseconds. This is not easy either: *FastDateFormat* accepts Java
> *Calendar*, which doesn't support. The not-so-good-but-okayish solution is
> to add a similar *#formatInstant()* method to *FastDateFormat*. What do you
> think?
>
> Kind regards.