Hoss, is there a clear replacement for facet.date? ...
facet.date was superceeded by facet.range in
SOLR-1240 - the internal methods were deprecated (so new internal code would be discouraged from using it) but we've always continued to support the functionality at the HTTP layer...
Aparently the SolrJ "FacetParams" associated with date faceting were never actually marked "deprecated", so that's another factor to the equation: https://lucene.apache.org/solr/4_10_1/solr-solrj/org/apache/solr/common/params/FacetParams.html#FACET_DATE
NOTE however: the SolrQuery faceting convinience methods – ie: addDateRangeFacet – have aparently always used facet.range. that feature deprecation evidently preceeded the creation of those solrj methods: https://svn.apache.org/r1150361 ... so the odds of any SolrJ clients actaully using facet.date are pretty low – but that doesn't say anything about people using solr from other clients or rolling their own requests
i have no opinion about removing the facet.date functionality from 5.0 - people shouldn't still be using it, but if we remove it and they are the inconvenience is painful: it will manifest either as client errors or silently returning no facet results (when the client tries to parse response data that isn't there) while the only benefit is less code on our end ... which is always nice, but hard to gauge on the value tradeoff – i defer judgement.
(unless of course: you want to add some logic to FacetComponent that returns a hard fail if "facet.date" is a specified param ... that might be a better error condition for client then just ripping the functionality out)