GitHub user ppkarwasz added a comment to the discussion: Getting current date-time format (or default format)
> 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](https://github.com/user-attachments/files/20959920/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 :wink:. 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`](https://logging.apache.org/log4j/2.x/manual/status-logger.html#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](https://github.com/apache/logging-log4j2/issues). GitHub link: https://github.com/apache/logging-log4j2/discussions/3788#discussioncomment-13615163 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
