Dear Solr Team, One use case we have with solr (we use 9.5) is to facet over months on a specific fields in our documents. We want to know how many documents there are each Month. But as you probably have guessed, the users of our app don't life in Greenwich (also their time changes two times a year ... yuck ...) So what we would need is to have the ability to get range facets but using another timezone. One simple way that one would probably try first is the following:
GET https://<link-to-solr>/solr/<collection>/query Accept: application/json Content-Type: application/json { "query": "*:*", "limit": 0, "facet": { "series": { "field": "<date-field>", "gap": "+1MONTH", "start": "2023-12-31T23:00:00Z/MONTH", "end": " 2024-04-30T22:00:00Z", "type": "range", "time-zone": "America/Los_Angeles" } } } This will obviously not work, as Solr calculates dates using UTC, and thus has no idea that 23:00 is actually midnight. It will continue to use 23:00 even for summer months (when some weird people have decided that in the summer midnight should be at 22:00 UTC). That's not what we want. But even more drastically, the first time February comes along, all precision concerning date calculations jump out the window for good, as solr will now continue to use the 29th 23:00 as the starting point for every month after it. This will now be 1 day and 1 hour off for all future winter months that are preceded by a 30 day month, and 2 days and 2 hours off for all summer months preceded by a 31 day month. As 2024 is a leap year the problem is huge, but not colossal as it would be in most other years where February only has 28 days. This is what we get (which is, as I have described, not what one would want to get) { "responseHeader": { "zkConnected": true, "status": 0, "QTime": 13, "params": { "json": "<the json request>" } }, "response": { "numFound": 2392751, "start": 0, "maxScore": 1.0, "numFoundExact": true, "docs": [] }, "facets": { "count": 2392751, "series": { "buckets": [ { "val": "2023-12-31T23:00:00Z", "count": 20749 }, { "val": "2024-01-31T23:00:00Z", "count": 18716 }, { "val": "2024-02-29T23:00:00Z", "count": 19230 }, { "val": "2024-03-29T23:00:00Z", "count": 19788 }, { "val": "2024-04-29T23:00:00Z", "count": 9215 } ] } } } So the solution would be to use TZ as described in https://solr.apache.org/guide/solr/9_5/indexing-guide/date-formatting-math.html#tz But somehow this does not work as advertised. It wrongly returns starting points in the perspective of utc aka: 00:00:00Z instead of 23:00:00Z) . In your example where you use America/Los_Angeles it shows that it correctly uses 2013-11-01T07:00:00Z and so on. I strongly suspect that this is called differently in the json api (considering "q" becomes "query" in the json api) GET https://<link-to-solr>/solr/<collection>/query Accept: application/json Content-Type: application/json { "query": "*:*", "limit": 0, "facet": { "series": { "hardend": false, "field": "<date-field>", "gap": "+1MONTH", "start": "2024-01-01T00:00:00Z/MONTH", "end": "2024-05-01T00:00:00Z", "type": "range", "TZ": "Europe/Zurich" } } } I even added "/MONTH" as I suspect that it would not work without. But sadly this does not make a difference. I also tried "tz" (not uppercase), "timezone", "time-zone", "time_zone" as a key, but none seem to work. Even when it would work, we would continue to have a problem, as solrj does not expose the functionality to supply a timezone as all constructors that are available are: it also does not allow one to use String for dates to use more advanced date features as NOW and /MONTH and calculations eg NOW-10YEARS. I know this is an edge case, but what if I want to use NOW when the request is processed by the solr server (as opposed to when its processed on our server before sending the request to solr) public RangeFacetMap(String field, long start, long end, long gap) public RangeFacetMap(String field, double start, double end, double gap) public RangeFacetMap(String field, Date start, Date end, String gap) Obviously I could use the less elegant way of constructing it by using a normal Map, but the main problem is still that it does not seem to apply the time zone. request.withFacet("series", Map.of( "hardend": false, "field": "<date-field>", "gap": "+1MONTH", "start": "2024-01-01T00:00:00Z/MONTH", "end": "2024-05-01T00:00:00Z", "type": "range", "TZ", "Europe/Zurich" )); If there is anything unclear with my question please feel free to demand clarification. With Kind Regards, Dario Viva