One I caught recently: The difference between the current time and one week from the current time is not always 7 * 86400 seconds.
By noticing an automated test that failed 2 weeks out of the year.
By noticing an automated test that failed 2 weeks out of the year.
If on the other hand it's just the test code that's flaky, usually such problems can be alleviated by refactoring such that one passes the time function as a parameter. This is in preference to hard-coding calls to the system time in test, which imho one should never do.
Once an arbitrary time function can be passed as a parameter, one can provide a mock or fake system clock for test purposes. Ideally one would still want to test under daylight savings' conditions. But at the least this approach leaves one in a place where one can test the common 24-hours-in-a-day case without having the tests spuriously fail two days out of every year.