On Sun, Jul 07, 2002 at 07:07:48PM +0100, Leon Brocard wrote: > It looks good to me... about 90% of the time. There's a timing problem > in t/date.t: [...] > (and so on) - so particular tests overlap the seconds changing. It's > probably best to force a specific date to be use in the date tests,
That was my first thought, but the alarm bells ringing made me look again. Good thing, too. The tests do use a fixed time. At the start of the script, we grab the current time and use that throughout. The problem it seems, was located between my keyboard and chair. I applied a patch from Keith Murphy adding the gmt flag, but decided to tweak^Hbreak it a little in the process. I mistakenly replaced: localtime($time) with localtime() and as a result, the Date plugin started ignoring its 'time' parameter, which of course was the one we were using in the test. If the test script ran in entirety before the second rolled over, then it would all work anyway because localtime() would return the same as localtime($time) anwyay. As soon as I added 'sleep 1' before calling test_expect(), the script failed reliably every $time. Once again, the test suite catches a stupid mistake that might otherwise have gone unnoticed for ages. Time spent writing tests is never time wasted. Thanks for catching it guys. It's fixed in CVS. I'll give it another day or so before putting it out as a developer release, just in case anything else shows up. A
