Yes, that bug is annoying, especially since specifying a todate that's before the fromdate returns a valid result set, EG:
{
"items": [],
"has_more": false,
"quota_max": 10000,
"quota_remaining": 9995
}
-- rather than an error. Having the dates be equal is theoretically possible. Having negative time is impossible (in this context).
However, having the same date may not mean what you think it means.
You probably want results from 2015-02-17, 00:00 AM to 2015-02-17, 12:59 PM, but the "date" parameters are really unix epoch time, so your sample query is giving you just 2015-02-17, 00:00 AM to the nearest second (Which could have valid results, but not what you probably expect).
To work around this issue, and to get a day's results, set the fromdate to the day you want and set the todate to the next day. EG: 2015-02-17 and 2015-02-18.
Or, more precisely: fromdate=1424131200&todate=1424217600
Additional buginess:
The API erroneously gives an error (and an unhelpful one too) if fromdate and todate are the same, but it also appears to give errors if they are not different by at least 100 seconds!
Using the doc page, I got:
Fromdate Todate Result ---------- ---------- -------- 1424131200 1424131200 500 error 1424131200 1424131201 500 error 1424131200 1424131210 500 error 1424131200 1424131260 500 error 1424131200 1424131300 Several valid results 1424044800 1424044800 "Violation of backoff parameter" !!?!!