I can’t think of any reason why we’d need fast date parsing. Unless it’s relevant in the rolling file appender family?
> On Nov 1, 2023, at 6:07 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > As reported in LOG4J2-3672 > <https://issues.apache.org/jira/browse//LOG4J2-3672>, `FastDateParser`[1] > contains `DateFormatSymbols#getZoneStrings()`, which causes initialization > and caching of all time zones, resulting in a ~3MB heap overhead on x86_64. > The reporter also provided the PR #1848 > <https://github.com/apache/logging-log4j2/pull/1848>, though it needs > several assumptions to hold to be effective. > > Curious: *In the context of logging, does `FastDateParser` need to be fast > while parsing?* We certainly need to *"format"* the instant fast. Though do > we really need to *"parse"* it fast too? > > [1] FDP was borrowed from Apache Commons Lang in 2015. I have checked the > most recent version > <https://github.com/apache/commons-lang/blob/5b5656a8b403fd91284b0d2acc893dac7ebd5c29/src/main/java/org/apache/commons/lang3/time/FastDateParser.java#L932>, > they still use `getZoneStrings()`.