*Conclusion:* I will make time zone parsing in `FastDateParser` *slow* to avoid `getZoneStrings()`.
*Remark:* JTL has the most versatile `Instant` formatter combining `FixedDateFormat`, `FastDateFormat`, and `DateTimeFormatter`. See `InstantFormatter` for why and how. I will later hoist this up to `log4j-core` and make sure every `Instant` formatting is performed via that. On Thu, Nov 2, 2023 at 12:27 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Ralph > > On Wed, 1 Nov 2023 at 23:53, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Actually we don't need a fast formatter either. Except for the rolling > > > file manager that can require a date from the past, the layouts format > > > timestamps close to 'now'. > > > > > > We can format all dates the same way `FixedDateFormat` does: we let > > > any date formatter to format the date part once a day and we format > > > the time part ourselves. > > > > Are we doing this now? If not, why not? The only trick is to ensure the > date gets formatted on or before the date rollover. > > Yes and no. If the user specifies one of a finite set of formats in > `FixedDateFormat.FixedFormat`, then we only format the date part once > a day. > If the user chooses another format, then we fall back on the Commons > Lang `FastDateFormat`. > > > One other thing though - don’t we allow different layouts to use > different date formats? We would need to ensure every layout is doing this. > > Different layouts format dates differently. E.g. PatternLayout uses > the patterns from the original `SimpleDateFormat`, while > JsonTemplateLayout uses the patterns from Java 8 `DateTimeFormatter`. > Under the hood they use `FixedDateFormat` if they can. We actually > have the unification of datetime formatting as one of our milestones. > > Piotr >
