Occasionally the testFilteringRangeGeekInterval fails on anydbm.
A "phase of the moon" defect that sometimes shows is not a good idea
for a test suite. ;) 

On the other hand, it is unsure how often and critical the combination
of geekinterval and anydbm is. This is the entry to track it.

A failure looks like:
 testFilteringRangeGeekInterval (test.test_anydbm.anydbmDBTest)
 in testFilteringRangeGeekInterval
    ae(filt(None, {'deadline': '-2d;'}), ['5', '6'])
        AssertionError: ['6'] != ['5', '6']

Testing on  4864:f630eb0adcee tip there have been failures.
It sometimes works, it sometime does not.

The problem was reported earlier as well, e.g. on May 2010 on ppc:
http://sourceforge.net/p/roundup/mailman/roundup-
devel/thread/201005100910.33550.bernhard%40intevation.de/#msg252
12241

So the next step is, to get this reproducable so more analysis can be 
done. One hypothesis is that this defect depends on the time.
To run this single test, someone can use:
  python run_tests.py anydbm  testFilteringRangeGeekInterval

Maybe a 
LOGGING_LEVEL=DEBUG anydbm testFilteringRangeGeekInterval
is better, but it produces a lot of output.

Here is a script to run the single test forever after 10-20 minutes of 
sleeping:

while true; do date ; python run_tests.py anydbm  
testFilteringRangeGeekInterval ; sleep `python3 -c 'import random; 
print(random.randrange(600,1200))'` ; done   >test-log-20140313.txt 
2>&1

The test created several deadline dates in the database and then
immediately queries for the interval depending on the current time.
Now if the clock ticked once after creation of the deadline dates the
test fails (because the querying interval is now too short by one second).

I've put the deadline dates one minute into the future.
Fixed in r74b24b14071a