I've implemented the changes in the way you and Piotr requested: https://github.com/apache/logging-log4j2/pull/3121 That is, implemented minute-precision caching and use `DateTimeFormatter` for sub-minute precision parts (e.g., `ss.SSS`). *Would you mind reviewing the changes, please?*
(Change implications and performance figures are in the ticket description.) On Tue, Oct 15, 2024 at 3:14 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Volkan, > > Piotr’s proposal sounds reasonable to me. Does it to you? > > Ralph > > > On Oct 15, 2024, at 4:36 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi Volkan, > > > > On Mon, 14 Oct 2024 at 21:30, Volkan Yazıcı <vol...@yazi.ci.invalid> > wrote: > >> Hence, I propose switching all layouts to use `DateTimeFormatter`, > unless > >> the `log4j.time.legacyFormatterEnabled` property is provided. > Objections? > > > > Can you upgrade `FixedDateFormat` to use DTF as date formatter and use > > it whenever it is applicable? > > The bug #2943 can IMHO opinion be fixed by changing the way > > `FixedDateFormat` caches the date part of the timestamp: > > > > * currently the cache consists of the "date string" and up to 25 > > offsets that associate each hour with the offset to UTC. The latter > > part is very prone to errors and will fail if a country decides to > > switch to DST at 2:30 am. > > * you can limit the cache to the "date string" and update the cache at > > the end of the day or the start of DST, whichever occurs first. Twice > > a year we will update the cache twice a day (at midnight and 2:00 am). > > > > If `FixedDateFormat` is fixed, we can use: > > > > * `FixedDateFormat` and `DateTimeFormatter` by default, > > * `FastDateFormat` if users enable the > > `log4j2.timeLegacyFormatterEnabled` (please use the post-2.10 > > normalized form). > > > > Piotr > > > > [1] https://github.com/apache/logging-log4j2/issues/2943 > >
