[LOG4J2-issue-3660] Add comprehensive unit tests for CronExpression daylight saving and scheduling logic

[ramanathan1504]

Issue #3660

Root cause (what was going wrong)

There were three related edge cases:

1. Strict-after boundary in getTimeAfter

   • getTimeAfter must move to the next second before evaluation.
   • Using +1ms can collapse back to the same second after millisecond truncation and return the same fire time again.

2. Millisecond input handling in getPrevFireTime

   • On rollover/restart paths, file timestamps often include milliseconds (e.g. ...00.201).
   • Without compensating for that, getPrevFireTime could resolve to the previous day around DST fallback boundaries, which can trigger an extra rollover.

3. Spring-forward (23-hour day) reverse-search step

   • Day-level reverse search used a fixed 24h step.
   • On 23h DST days, that can skip over a valid previous fire time.

Fix implemented

In log4j-core/src/main/java/org/apache/logging/log4j/core/util/CronExpression.java:

• getTimeAfter(...): keep strict next-second behavior (+1000 ms).
• getPrevFireTime(...): for inputs with millisecond fraction, shift by +999ms before delegating to getTimeBefore(...).
• findMinIncrement(): for day-level fallback increment, use 23h minimum step to remain DST-safe on spring-forward days.

Validation

log4j-core-test/src/test/java/org/apache/logging/log4j/core/util/CronExpressionTest.java now includes/contains DST cases for:

• fallback at 2AM (Australia/Sydney)
• fallback at midnight (America/Santiago)
• spring-forward 23h day (Australia/Sydney)

Current result locally:

• CronExpressionTest: 16 run, 0 failures

This addresses the “twice-a-year” DST rollover corruption path you described, including both fallback ambiguity and spring-forward short-day behavior.