I think it would make sense to switch to the standard Java one. The custom classes mostly predated Java 8, and I’ve seen enough test failures whenever daylight saving time starts or ends to know that they’re buggy.
> On Oct 14, 2024, at 14:30, Volkan Yazıcı <vol...@yazi.ci.INVALID> wrote: > > *Abstract:* Log4j contains two custom date & time formatting classes. All > our competitors (Logback > <https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/util/CachingDateFormatter.java>, > Tinylog > <https://github.com/tinylog-org/tinylog/blob/7590ad150b1523691ae6f26ae24a291b81d804c9/tinylog-api/src/main/java/org/tinylog/runtime/PreciseTimestampFormatter.java>, > etc.) use Java's `DateTimeFormatter` and I know of no user complaints about > their performance issues. Shall we switch to `DateTimeFormatter` as the > default in the next minor release and make the custom implementations > opt-in? > > Log4j ships two custom date & time formatting classes: > > - `FixedDateFormat` > - Supports a hardcoded list of formats > - Bug: Conflates `n` directive with `S` > - Bug: It cannot calculate DST correctly for all time zones > <https://github.com/apache/logging-log4j2/issues/2943> > - `FastDateFormat` > - Copied from Commons Lang in 2015 > > I recently ran a test comparing the output of these with > `DateTimeFormatter` – the difference is *big*! I can spend months fixing > these issues, but... Do we really need them? > > 1. No other competitors have such an optimization (both Logback > > <https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/util/CachingDateFormatter.java> > and Tinylog > > <https://github.com/tinylog-org/tinylog/blob/7590ad150b1523691ae6f26ae24a291b81d804c9/tinylog-api/src/main/java/org/tinylog/runtime/PreciseTimestampFormatter.java> > use > `DateTimeFormatter`) > 2. Date & time formatting is very fragile (DST is more voodoo than > science) > 3. If date & time formatting during logging is found to be the > bottleneck of an application, shouldn't they instead encode it differently, > e.g., encoding epoch numbers? > 4. `DateTimeFormatter` performance will only get better over time > > Hence, I propose switching all layouts to use `DateTimeFormatter`, unless > the `log4j.time.legacyFormatterEnabled` property is provided. Objections? > > Note that the caching optimization we have for the last formatted timestamp > will stay untouched.
