rgoers opened a new pull request, #4405: URL: https://github.com/apache/logging-log4j2/pull/4405
CronExpressionTest intermittently fails because of the time of day the test JVM starts, not because of the machine, the JDK or the timezone data. It only fails when the default timezone is west of UTC and the run starts late enough in the day. Cause: in CronExpression.java:256-263, the lower bound is built like this: MIN_CAL = Calendar.getInstance(); // now, in the default zone MIN_CAL.set(1970, 0, 1); // changes only year/month/day; time of day stays MIN_DATE = MIN_CAL.getTime(); So MIN_DATE ends up as 1970-01-01 at whatever local time the JVM started, not the epoch. getTimeBefore (line 1588) returns null for any previous fire time before MIN_DATE. The test expects 1970-01-02T00:00Z. In America/Phoenix (UTC-7), which this Mac uses, that instant is 1970-01-01 17:00 local. So a run started after 17:00 gets null and the test errors. In Los Angeles the cutoff is 16:00, and in UTC or any zone east of it the test never fails. The test passed on a different computer because of when it ran or which zone it’s set to, not because it’s newer. Evidence from the investigation session: The real test passed when run at 13:33 MST. A simulation that set MIN_DATE to the value it would get at different start times failed in Phoenix from 17:30 on, and never failed in UTC or Berlin. The code and the test assertion were checked by Claude (who created this fix) and they match this explanation. Fix: make the bound the epoch, for example with MIN_CAL.setTimeInMillis(0) or MIN_DATE = new Date(0). That affects real getPrevFireTime calls near 1970 too, not just this test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
