Agreed. I prefer the quick win to get us back to successful builds. I do think it's worth a general discussion around how we want to handle the parsing of string dates with no year. In the long run, Matt's suggestion of incorporating the Clock object is probably the route to go; albeit as a separate enhancement PR.
I'll start a new discuss thread for that and submit a PR for the quick fix. -Kyle > On Jan 3, 2017, at 5:20 PM, David Lyle <[email protected]> wrote: > > I'm not sure I'm an owner, but I have an opinion. :) > > I'd just add "2016". Easy and targeted. > > -D... > > >> On Tue, Jan 3, 2017 at 5:08 PM, Matt Foley <[email protected]> wrote: >> >> I’ll subordinate this to METRON-647 since it was evidently filed while I >> was writing METRON-648 (I did check before!) >> >> The question below remains valid, however… >> >> >> On 1/3/17, 1:59 PM, "Matt Foley" <[email protected]> wrote: >> >> Hi all, >> As described in https://issues.apache.org/jira/browse/METRON-648 , >> these two test modules are not year-safe, and are suddenly (as of 2017) >> giving false Travis errors. >> >> I can fix it quickly, but a question for the “owners” of GrokParser: >> Do you have an opinion as to whether the fix should be done by adding >> "2016" to the testString values in the GrokWebSphereParserTest test module >> (easy, and only affects the test module), vs making GrokParser use a Clock >> object set to 2016 (more involved, and affecting core code, but allowing >> for more interesting testing)? >> >> For those interested, BasicAsaParserTest::testShortTimestamp() >> illustrates the use of Clock object in the Asa Parser and its test module. >> >> Thanks, >> --Matt >> >> >> >> >> >> >>
