todate and fromdate always refer to creation date.
min and 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 min and max can be of any number of types.
/search for example.
We try and do "what's expected" given a sort value.
sort can be of some set of values depending (and documented on) the route in question. Common values are creation, activity, name, and the like.
Generally, the value of sort corresponds to a field in the returned objects to sort by:
creation->creation_datename->display_nameactivity->last_activity_date- and so on...
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 on users/{id}/favorites.
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 min and 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 min and max must fall in the same range.
hot, week, and 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. min and 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.