Quote:
Originally Posted by DaWei
Slow your code down? Get real.
Yes.. slow your code down.
Quote:
Originally Posted by DaWei
He's doing this calculation every few milliseconds?
You have no idea what he's using this for and assuming anything means you're wrong. Wrong in the same way that people felt they could store years using only 2 digits. If the year 2000 debacle taught us anything its that you simply can't make assumptions on how long this code will be used for, or where. The customer says he wants dates in the form of mm/dd/yyyy and you'd better be able to handle mm/dd/yyyy and not come back to them and say 'Sorry pal.. I can do it.. but we need to keep the dates between 1970 and 2038'.
The fact is.. its a straightforward problem to address and you do not need to go about it in a round-a-bout manner that not only takes a quite a bit of processing time to accomplish.. but fails if the dates do not stick to your specified constraints.
Quote:
Originally Posted by DaWei
He's measuring intervals back before he even knew what calendar was in use? The year 3000 is far too close to take a chance on? Bub, you need to achieve some practicality.
I am infinitely practical.. I solve the solution per the requirements given.. preferably using only the processing time needed to actually solve the problem.
If two dates aren't in concurrent years or the same year.. what are they? More than 5 days apart. In that situation it takes really no processing whatsoever other than a subtraction, a branch, with a return. Even breaking down to the wildest of the wild situations.. like 2 dates in the same year happen to cross what might be a leap day ... the years are divisible by 4 and 100 but not by 400... the code in that situation would be over and done with before your first _mktime call even returned an answer.