Before I can weigh in one way or another I would need to know what the performance difference is between DateTimeFormatter and the Fixed and Fast classes, at least where they are working properly. Any such test should include the caching otherwise you would be comparing worst case performance.
Ralph > On Oct 14, 2024, at 12:30 PM, 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.
