I have noticed this on all sorted routes.
The min/max say that they are context sensitive to the sort type yet are documented as
How is a date min/max valid when sorting by, for instance votes?
fromdate always refer to creation date.
max are with respect to the current
sort. So, where
sort=votes they place upper and lower bounds on the
score of returned answers/questions.
They can overlap, but do not always do so.
Documentation has been updated to reflect that
max can be of any number of types.
/search for example.
We try and do "what's expected" given a
sort can be of some set of values depending (and documented on) the route in question. Common values are
name, and the like.
Generally, the value of
sort corresponds to a field in the returned objects to sort by:
In rare cases the sorted field is something that is not exposed by the API - generally as a consequence of being hidden on the site, or only shown to logged in user - such as
added sorts returned questions by the date the user in question "favorited" them. As we don't display such information anywhere on the site, its not returned by the API.
While the possible types of
max is (now) documented, the range can be inferred based on context. Namely, if the field being sorted has a certain range (
votes for instance being positive and negative integers,
creation_date being >= Jan 1 1970, etc.) then
max must fall in the same range.
month sorts are strange beasts. The ordering of the returned results is dependent on the "hotness" - an intentionally undocumented algorithm, subject to change, which drives the front page of the sites - of a set of questions.
max on these sorts restricts questions by
last_activity_date. This is something of a compromise. The API can't really take in "hotness" values, since we can't/won't document them, but it we do acknowledge that they are in some way influenced by
last_activity_date; so we let you pass those in for a range.