If the tests are failing because the production code is confused about daylight savings time, then you may have a serious problem.

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.