If I want midnight in Central time zone I shouldn't have to write: 2011-01-01T06:00:00Z (Note I wrote 6:00 not 0:00)
"Central time zone" is a vague concept that may mean one thing to you, but may mean something different to someone else. For any arbitrary moment in the (one dimensional) space of time values, there are an infinite number of ways to represent that time as a string (or as number) depending on where you place your origin for the coordinate system. Requiring that clients format times in UTC is no different then requiring clients to use Arabic numerals to represent integers – it's just a matter of making sure there is no ambiguity, and everyone is using the same definition of "0". UTC is a completely unambiguous coordinate system for times, that is guaranteed to work in any JVM that Solr might run on. Even if we added code to allow dates to be expressed in arbitrary user selected timezones, we couldn't make that garuntee.
Bottom line: the issue of parsing/formatting times in other coordinate systems (ie: timezones) should not be convoluted with the issue of what timezone is used by the DateMathParser when rounding – those are distinct issues. It's completely conceivable to have a QParser that accepts a variety of data formats and "guesses" what TZ is meant and use that QParser in the same request where you want date faceting based on a TZ that is specified distinctly from the query string (ie: user's local TZ is UTC-0700, but they are searching for records dated before "Dec 15, 2010 4:20PM EST")
So one possible alternative that needs more thought is a "TZ" request parameter that would apply by default to things that are date related.
Right ... from the beginning DateMathparser was designed with the hope that a TZ/Locale pair could be specified per request (or per field declaration) for driving the rounding/math logic, there was just no sane way to specify an alternative to UTC/US that could be past down into the DateMathParser and used ubiquitously in a request because of the FieldType API.
its really only essential that we can affect DateMathParser the SimpleFacets uses when dealing with the gap of the date facets.
...just changing the TZ used by that instance of DateMathParser for rounding/math isn't going to do any good if the user then tries to filter on one of those constraints and the filter query code winds up using the defaults in DateField (ie: NOW/DAY and NOW/DAY+1HOUR are going to be very differnet things in the facet count code path vs the filter query code path))
Now that we have SolrRequestInfo and a request param to specify the meaning of "NOW", the same logic could be used to allow a request param to specify the TZ/Locale properties of the DateMathParser as well.
But like I said: this should really only be used to affect the math in DateMathParser – it should not be used in DateField.parseDate/formatDate because DateField by definition deals with a single canonical time format, by the time the DateField class is involved in dealing with a Date everything should be un-ambiguisly expressable in UTC.
logic for parsing date strings that aren't in the canonical date format should be a QParser responsibility at query time, or an UpdateProcessor responsibility at index time. Logic for formatting dates in non-canonical format should be a ResponseWriter responsibility. This new request property we're talking about for defining the "users TZ" can certainly be used in all of these places to pick/override defaults, but that type of logic really doesn't belong in DateField.