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" !!?!!