Falsehoods Programmers believe about Time

points in time are relative to some fixed point, and are (more or less) dimensionless. durations are not, and are (more or less) vectors. this has a couple consequences: durations are independent of epoch, while points aren't, and only certain types of math make sense with each.

basically, the only thing you can do with two points is subtract them (yielding a duration)--the rest of arithmetic (including addition) is meaningless. the only things you can do with a point and a duration is add or subtract them (yielding a point). you can't do anything at all with a point and a dimensionless scalar. the only things you can do with two durations is add or subtract them (yielding a duration) or divide them (yielding a scalar). the only things you can do with a duration and a scalar is multiply or divide them.

(personally i'd say that even the commutative operations shouldn't necessarily be commutative--i'd say point+duration->point, but duration+point->undefined--but that may be a bit too strict.)

as a quick rule of thumb, if your code would break if you changed epochs, it's already broken.

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.