Getting current date-time format (or default format)

[ashr123]

As of now, I'm using %d{DEFAULT} date-time layout, since version 2.25.0, all org.apache.logging.log4j.core.util.datetime had become deprecated, including FixedDateFormat which I've used its FixedDateFormat.FixedFormat.DEFAULT.getPattern().
It seems like the new way to derive the default pattern is through org.apache.logging.log4j.core.pattern.DatePatternConverter#DEFAULT_PATTERN, but there is no way to use it as it's not public in any way.
Is there a workaround?

[ppkarwasz]

Thanks for the question!

Could you tell us more about your use case? For example, are you trying to introspect the effective Log4j Core configuration at runtime, or are you attempting to parse the output of a PatternLayout?

If you're aiming to parse logs, keep in mind that most formats produced by PatternLayout aren't designed to be reliably machine-parsed. In such cases, we strongly recommend using a structured logging format (like JsonTemplateLayout) instead.

As for the default datetime pattern, it's currently yyyy-MM-dd HH:mm:ss,SSS. This pattern has been stable for a long time and is unlikely to change anytime soon due to backward compatibility. We could make the DatePatternConverter#DEFAULT_PATTERN public, but referencing it in your own code may not be ideal, though—it’s a compile-time constant. If Log4j Core changes that value in a future version, your compiled code will retain the old value unless you recompile against the updated library.

Let us know more about what you're trying to achieve—we're happy to offer more specific guidance!

[ppkarwasz]

If you chose the yyyy-MM-dd HH:mm:ss,SSS format because it was one of the few formats optimized for low garbage generation by FixedDateFormat, it's worth noting that this limitation no longer applies as of Log4j 2.25.0.

We deprecated FixedDateFormat primarily because #3121 introduced a new, more consistent timestamp formatting subsystem. This new implementation is also optimized for performance and low garbage generation, but with the added flexibility of supporting any DateTimeFormatter pattern—including formats like the one used in the Last-Modified HTTP header.

[ashr123]

First of all, thank you for answering 🙂
Second, regarding your first comment (i didn't want to quote it) is't not up for the user to decide how the time will be formatted, I'm the one who controls it via the attached log4j2.json.
I wanted to let Log4J to take the lead regarding the formatting as I agree the default formatting won't probably change.
When I used FixedDateFormat.FixedFormat.DEFAULT.getPattern() I meant to say

I didn't came up with the pattern, I took it from that place and if one day they will change it to something else, I'm ok with that and when I'll upgrade to a new version, it will be changed too

3rd, regarding your last comment, i know that as of version 2.25.0 FixedDateFormat is deprecated, this is why we have this discussion 🙂
By the way, i'm parsing the Last-Modified HTTP header like so:

final Optional<Instant> lastModified = httpResponse.headers().firstValue("Last-Modified")
        .map(lastModifiedStr -> DateTimeFormatter.RFC_1123_DATE_TIME.parse(lastModifiedStr, Instant::from))

Where httpResponse is of type java.net.http.HttpResponse and is created from java.net.http.HttpClient

I hope that I understood you correctly and that was clear 🙂

[ashr123]

See #3789

[ppkarwasz]

First of all, thank you for answering 🙂 Second, regarding your first comment (i didn't want to quote it) is't not up for the user to decide how the time will be formatted, I'm the one who controls it via the attached log4j2.json. I wanted to let Log4J to take the lead regarding the formatting as I agree the default formatting won't probably change. When I used FixedDateFormat.FixedFormat.DEFAULT.getPattern() I meant to say

I didn't came up with the pattern, I took it from that place and if one day they will change it to something else, I'm ok with that and when I'll upgrade to a new version, it will be changed too

We certainly appreciate that you’ve chosen to align your application’s timestamp format with Log4j Core’s default 😉. That said, I think the responsibility hierarchy around who “decides” the timestamp format might be slightly different from how you described it. Here's how I see it:

1. The user (your application's end user or operator) should ultimately have the final say on timestamp formatting—if they need it. Of course, until such a need arises, it’s perfectly reasonable not to expose this as a configurable option.
2. You, as the application developer, come next. Since you clearly value consistency between your own output and Log4j logs, I think it’s better to explicitly set the format (e.g., %d{yyyy-MM-dd HH:mm:ss,SSS}) rather than rely on Log4j’s default. This makes your intent clear and guards against potential surprises if the default ever changes.
3. Log4j only determines the format by default if no one else does—it acts as a fallback, not the source of truth.

From this perspective, I feel even more confident that while the default timestamp format should absolutely be documented, it should not be exposed programmatically.

Note on Timestamp Format Consistency in Log4j

Since you care about timestamp consistency, you’ve probably noticed that Log4j Core does not use a uniform date-time format across all components:

• The default format for %d in PatternLayout is:
  yyyy-MM-dd HH:mm:ss,SSS

• The default format for the status logger is equivalent to Instant.toString():
  yyyy-MM-dd'T'HH:mm:ss,nnnnnnnnn'Z'
  This can be customized via the log4j2.statusLoggerDateFormat system property.

• Timestamps from logged parameters that implement java.time.Temporal or extend java.util.Date depend on their respective toString() implementations. Here are the effective formats:

  Type	Effective Format
  java.util.Date	yyyy-MM-dd'T'HH:mm:ss.SSSZ
  java.time.Instant	yyyy-MM-dd'T'HH:mm:ss,nnnnnnnnn'Z'
  java.sql.Date	yyyy-MM-dd
  java.time.LocalDate	yyyy-MM-dd
  java.sql.Timestamp	yyyy-MM-dd'T'HH:mm:ss.SSSZ
  java.time.LocalDateTime	yyyy-MM-dd'T'HH:mm:ss,nnnnnnnnn

This inconsistency can be surprising and may complicate downstream parsing or formatting.
It could be helpful to introduce more uniform timestamp formatting across Log4j Core. For example:

• Use a common (and configurable) format for %d, java.util.Date, and java.time.Instant, possibly via a shared configuration property.
• Standardize java.sql.Timestamp and java.time.LocalDateTime to use a single, fixed format.

If you think such a change would improve your experience or benefit others, feel free to open a feature request.