場景描述：

        上一篇分面查詢文章中，我們提到了時間區間分面，但是在使用的過程中，遇到了很坑的事情，那就是時區。

        如果忽視時區，直接設定時間，時間分面查詢的結果。很自然的你會設定起始時間都為該月1號00:00:00，但是因為時區的問題，在Solrj處理之後傳送給伺服器查詢時，你可以通過debug看到他的查詢條件處理成減了8小時。也就變成了上個月最後一天的16:00:00，如果是31天的月還好，只要到2月就會很複雜。如果是閏年的2月，更會讓你頭大，導致後面的所有月份分割都會受到影響，就比如3月會因為閏年2月的28號的影響導致分面結果在3月28號就切割，那問題來了，3月29號就算在了下一個區間裡，這顯然是錯誤的。

        然而網上大部分的文章遇到該問題並沒有人注意到，而只是告訴你們有這個東西，那有什麼用，錯誤的東西拿過來用有意義嗎？下面是設定錯誤的示例，也就是大部分的網友發的樣式：

這種結果是錯誤，一般是沒有意義的！

"facet_counts":{  
    "facet_queries":{},  
    "facet_fields":{},  
    "facet_dates":{  
      "birthday":{  
        "2013-12-31T09:15:00Z":0,  
        "2014-01-31T09:15:00Z":0,  
        "2014-02-28T09:15:00Z":0,  
        "2014-03-28T09:15:00Z":0,  
        "2014-04-28T09:15:00Z":0,  
        "2014-05-28T09:15:00Z":0,  
        "2014-06-28T09:15:00Z":0,  
        "2014-07-28T09:15:00Z":0,  
        "2014-08-28T09:15:00Z":0,  
        "2014-09-28T09:15:00Z":1,  
        "2014-10-28T09:15:00Z":5,  
        "2014-11-28T09:15:00Z":3,  
        "gap":"+1MONTH",  
        "start":"2013-12-31T09:15:00Z",  
        "end":"2014-12-28T09:15:00Z"}},  
    "facet_ranges":{}}}  
 

這樣才是正確的結果：

<lst name="facet_ranges">
	<lst name="CREATE_TIME">
		<lst name="counts">
			<int name="2017-02-01T00:00:00Z">4</int>
			<int name="2017-03-01T00:00:00Z">6</int>
			<int name="2017-04-01T00:00:00Z">3</int>
			<int name="2017-05-01T00:00:00Z">4</int>
			<int name="2017-06-01T00:00:00Z">2</int>
			<int name="2017-07-01T00:00:00Z">3</int>
			<int name="2017-08-01T00:00:00Z">11</int>
			<int name="2017-09-01T00:00:00Z">2</int>
		</lst>
		<str name="gap">+1MONTH</str>
		<date name="start">2010-01-01T00:00:00Z</date>
		<date name="end">2018-07-01T00:00:00Z</date>
	</lst>
</lst>
 

解決辦法：

        這是因為時區的問題，我們的時間在處理之後少了8小時，當然也可以去設定配置的時區，也可以去原始碼中修改時區，我的辦法是在給他引數的時候給他加上8小時。