[
https://issues.apache.org/jira/browse/METRON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15796351#comment-15796351
]
Matt Foley commented on METRON-648:
-----------------------------------
This is a dup of METRON-647.
> GrokWebSphereParserTest and BasicAsaParserTest are not 2017-safe
> ----------------------------------------------------------------
>
> Key: METRON-648
> URL: https://issues.apache.org/jira/browse/METRON-648
> Project: Metron
> Issue Type: Bug
> Affects Versions: 0.3.0
> Environment: Travis operating on branch master
> Reporter: Matt Foley
>
> In
> metron-platform/metron-parsers/src/test/java/org/apache/metron/parsers/websphere/GrokWebSphereParserTest.java
> eight of the test cases use a testString with log contents including a
> timestamp of "Apr 15" without year specified, then do an assertEquals()
> comparison against a hardwired epoch value that assumes a "Apr 15 2016"
> interpretation.
> Unfortunately, now that local time is 2017, it is interpreting these logs as
> "Apr 15 2017", even though that is in the future from now (Jan 3 as of this
> writing). This causes Travis failures without other cause.
> BTW, the assertEquals() calls incorrectly give arguments in order (actual,
> expected) instead of the correct order (expected, actual), so the error
> message was confusing. It said, e.g., {code}expected:<14[92278]448000> but
> was:<14[60742]448000>{code} and yet the code says
> {code}assertEquals(parsedJSON.get("timestamp") + "", "1460742448000");{code}
> Whoever fixes this, please fix that too.
> The same problem occurs in one test case of
> metron-platform/metron-parsers/src/test/java/org/apache/metron/parsers/asa/BasicAsaParserTest.java::testIp6Addr()
> , where the assertTrue() timestamp comparison fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
