I think it depends on you definition of "Unit Test". Some people do a "sanity check" time test just to verify the function works. Those who want a better test will use a code coverage tool and will add test cases untill every path through the function is exercised.
One thing to remember is NO TEST can prove a function correct, you can only prove it wrong. No matter how many tests you do yo only gain confedance that the function is likely not bad. A famous "proof" goes like this: Can I divide 60 by 1? Yes of course, by 2? yes, by 3, by 4, by 5 , by 6 all yes but this is going to slow so let's try 10, 20 ,30. Ok end of proof: 60 is divisible by all integers. Sady, software unit tests can only be as good as this proof. So just use enough tet cases to exercise every code path and then you will know there is nothing "stupid wrong" with it. On Wed, Jun 12, 2013 at 8:02 PM, Tom Van Baak <t...@leapsecond.com> wrote: > > 12/31/1998 00:00:00 EST + 5184001 seconds = Time Date in UTC > > > 01/01/1991 11:01 AM EST = XX/XX/XXXX XX:XX UTC > > Doug, > > This is difficult (or impossible) to do right; at a minimum you need a > table of all past, current, and future national timezone definitions, DST > rules by locale, and leap seconds. Start by defining your problem very > explicitly, down to each character, digit, integer, and allowable range. > > I think there is a timezone mailing list that would better be able to > answer your question. They may point you to a number of well tested > libraries that already do this sort of thing. > > /tvb > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
