Note: this condition can only be reached while tampering the url manually. It might be possible to argue that the suggested solution is do-what-i-mean in most cases, but not all.

Have you verified that the days parameter is the problem? From your description of the problem, it sounds like you're speculating. The real problem is most likely that recent changes entries are deleted after 30 days.

tampering the url manually.

The user is very much led to tampering with the URL, as there is no
other way of adjusting the date produced by the click, other than the
juicy URL sitting there waiting to be tampered with.

verified that the days parameter is the problem?

As you can see from the above output
&from=20070301000000&days=777 produced output, but
&from=20070301000000&days=77 didn't.

recent changes entries are deleted after 30 days.

Ah, but only perhaps when a new change is made.

And even then, it would only be polite if Recentchanges took a lesson
from the last(1) command:
$ last jidanni
jidanni pts/0 122-127-32-142.d Tue Mar 3 10:18 still logged in
jidanni pts/0 122-127-39-141.d Mon Mar 2 15:22 - 17:25 (02:03)

wtmp begins Sun Mar 1 22:28:19 2009

I.e., it tells the user why he didn't login last month... the records
are gone, so it admits it doesn't know.

For the MediaWiki case this is hard to test, as most wikis are very
busy.

However, for the case where the listing ends, and it is not because
we have reached limit=, nor days=, nor due to from=, well, in this case it is
because we have reached the end of the available data, and a message
about that fact should be appended to the bottom, so the user can
distinguish the case of no activity, vs. possible gone activity.
Maybe that should be a separate bug.
Sorry I don't have any diffs for you,
I would probably just make things worse.