Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Done. On Thu, Nov 2, 2023 at 6:58 PM Piotr P. Karwasz wrote: > Hi Volkan, > > On Thu, 2 Nov 2023 at 18:50, Volkan Yazıcı wrote: > > > > I guess the safest alternative would be to lazily initialize the > > `FastDateFormat#parser` field. > > I am happy we agree on the right solution, respectful o

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

I guess the safest alternative would be to lazily initialize the `FastDateFormat#parser` field. Nevertheless, I do not want to miss this deprecation unicorn, and hence, deleted the code and some tests

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Hi Volkan, On Thu, 2 Nov 2023 at 18:50, Volkan Yazıcı wrote: > > I guess the safest alternative would be to lazily initialize the > `FastDateFormat#parser` field. I am happy we agree on the right solution, respectful of the public API! Now you have my blessing to shred those unused classes to pi

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Hi Volkan, On Thu, 2 Nov 2023 at 16:16, Volkan Yazıcı wrote: > I deleted all date parsing functionality in Log4j[1] and the compilation... > [drum roll...] succeeded. I am inclined to commit this breaking change. We > can refer users who were previously using Log4j to parse dates (ugh!) to > Comm

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Log4j to parse dates (ugh!) to > Commons Lang. The API is identical, they simply need to use a > separate package. *Objections?* > > [1] To be precise, in `org.apache.logging.log4j.core.util.datetime` > package, some methods from `FastDateFormat` and `Format`, and > `FastDateParser

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

package. *Objections?* [1] To be precise, in `org.apache.logging.log4j.core.util.datetime` package, some methods from `FastDateFormat` and `Format`, and `FastDateParser[Test]` classes. That is, touched to 4 files in total. On Thu, Nov 2, 2023 at 10:00 AM Volkan Yazıcı wrote: > *Conclusion:* I w

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

*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

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Hi Ralph On Wed, 1 Nov 2023 at 23:53, Ralph Goers wrote: > > On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz > > 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

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

> On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz wrote: > > Hi Volkan, > > On Wed, 1 Nov 2023 at 12:07, Volkan Yazıcı wrote: >> Curious: *In the context of logging, does `FastDateParser` need to be fast >> while parsing?* We certainly need to *"format&quo

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

Hi Volkan, On Wed, 1 Nov 2023 at 12:07, Volkan Yazıcı wrote: > 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? No

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

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ı wrote: > > As reported in LOG4J2-3672 > <https://issues.apache.org/jira/browse//LOG4J2-3672>, `FastDatePar

[LOG4J2-3672] Time zone parsing in `FastDateParser`

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

Re: FastDateParser

On Thu, Feb 25, 2021 at 3:15 AM Volkan Yazıcı wrote: > Shall we create a JIRA ticket on our board for this issue with this > diagnosis information attached? > It might be worth copying the code and the tests again from Commons Lang as I assume we do not want a dependency on the jar. Gary > >

Re: FastDateParser

Shall we create a JIRA ticket on our board for this issue with this diagnosis information attached? On Wed, Feb 24, 2021 at 5:42 PM Gary Gregory wrote: > Voila: > > org.apache.logging.log4j.core.util.datetime (Java 16) > > org.apache.logging.log4j.core.util.datetime.FastDateParserTest > > > test

Re: FastDateParser

Sorry about the formatting copied on Windows/emailed/Pasted on Mac in gmail. Corporate policies... G On Wed, Feb 24, 2021 at 12:18 PM Ralph Goers wrote: > > Formatting sucks but thanks! > > Ralph > > > On Feb 24, 2021, at 9:42 AM, Gary Gregory wrote: > > > > Voila: > > > > org.apache.logging.lo

Re: FastDateParser

Formatting sucks but thanks! Ralph > On Feb 24, 2021, at 9:42 AM, Gary Gregory wrote: > > Voila: > > org.apache.logging.log4j.core.util.datetime (Java 16) > > org.apache.logging.log4j.core.util.datetime.FastDateParserTest > > testLocales_Long_AD(org.apache.logging.log4j.core.util.datetime.Fa

Re: FastDateParser

Voila: org.apache.logging.log4j.core.util.datetime (Java 16) org.apache.logging.log4j.core.util.datetime.FastDateParserTest testLocales_Long_AD(org.apache.logging.log4j.core.util.datetime.FastDateParserTest) java.lang.AssertionError: sr__#Cyrl н. е./2003/фебруар/0009/0007//00/по подне/недељ

Re: FastDateParser

Thanks for checking. Can you provide details? Ralph > On Feb 24, 2021, at 8:16 AM, Gary Gregory wrote: > > In 2.x git, the datetime package fails 9 tests under Java 16 EA 36. > > On Wed, Feb 24, 2021, 01:49 Ralph Goers wrote: > >> Gary, >> >> As you

Re: FastDateParser

In 2.x git, the datetime package fails 9 tests under Java 16 EA 36. On Wed, Feb 24, 2021, 01:49 Ralph Goers wrote: > Gary, > > As you know our FastDateParser was borrowed from Apache Commons and > modified for our purposes. You picked up bug fixes from Apache Commons > several y

FastDateParser

Gary, As you know our FastDateParser was borrowed from Apache Commons and modified for our purposes. You picked up bug fixes from Apache Commons several years ago. I noticed you posted that Apache Commons’ version of this class is failing a test in Java-16 EA. Do you happen to know if our