>>(2) Not sure if the original reason for limiting time frames was to limit server load or to improve response time for for the user doing the search. If the latter, then allowing the user finer control of the timeframe bounds is a possibility. If the former, UT's current solution seems optimum, though I'd probably make the primary category be 'The last six months' rather than the 'last half calendar year' since the latter filter reduces the default search timeframe to a relatively small number of messages depending on what time of the year you actually do the search.
>
>AFAI remember, both reasons. Fixed time frames allows for storing each 6 months in a separate table, thus performance improvement.
>
>Vlad
As I said before, the features are built with making it easier for the server AND programmer in mind, user comes last. Sound familiar?