TDD pro-tip: any "time" u refer to a clock, be on the lookout.
it's a time -- i just can't help myself -- to seriously microtest your way through.
if you have to talk about "now", consider whether you want to be able to pass a clock rather than call the system. for the price of an additional argument, you get perfect testability.
the price of resistance? your now-based object will have to be thought about every time you place it inside another object as a component.
some middle grounds that might be appropriate: 1) use a default argument for that clock. 2) use a global with settability -- what most people naively call a singleton.
when you do clock or date math, always always always test *on* the boundary point in addition to clearly-before and clearly-after. if you don't, you're sure to blow inclusive/exclusive endpoints for durations.
never assume that two calls to the system now have a certain gap between them. two calls to now might be the same time, they might be split by a tiny amount, they might be split by a lot. it is not a countable-on kinda thing.
finally, if you're manipulating times a lot, please do use a serious library rather than rolling your own. it's not cuz i'm against re-inventing wheels, i do that all the time.
it *is* about efficiency, but not in the way you think. you are so extraordinarily likely to handle the complexities of time and date correctly against all cases that you will waste way too much time -- lord, help me -- later debugging corner cases.
oh wait, i got another, cuz joe was responding in real time -- help! i'm trapped in a pun factory -- think of time as a set of timestamps, and think of them as potentially going backwards. yes. backwards.
that's all. have fun.
oops, on re-read. that should be "you are so extraordinarily *un* likely to handle..." in other words, you're gonna screw up a million different ways and spend the rest of your life sitting cold and lonely on a parkbench with a bottle and NO FRIENDS.
