我的solr中有一個數據：Using the Solr Administration User Interface，modifyTime是「2016-04-20T13：58：35.805Z」。使用solrj獲取8小時的日期差異

使用solrj： enter image description here，該modifyTime是「週三4月20日21時58分35秒CST 2016」。

我使用solr6。爲什麼？

2016-07-25 finemi

這是因爲你有兩臺機器（機器承載Solr的和本地機）不同的時區，本地機器採用CST作爲默認的時區，你可以請Solr的機器上的默認時區？ – NAIT

從Solr的管理用戶界面來modifyTime數據格式爲UTC，您可以通過在時間字符串的結尾在Z明白，這表明日該字符串表示是在UTC。

2016-04-20T13:58:35.805Z

在另一方面，modifyTime從數據格式來爲CST - 中央中國標準時間，而你的情況似乎是+ 8小時。

Wed Apr 20 21:58:35 CST 2016

這是因爲一個Java惱人的壞特徵，其中與java.util.Date沒有時區的但它的toString方法適用於JVM的當前默認時區。

java.util.Date date = (java.util.Date) doc.getFieldValue("modifyTime"); 
DateTime dateTimeUtc = new DateTime(date, DateTimeZone.UTC); 
String output = dateTimeUtc.toString();

編輯

感謝@BasilBourque對CST（時區的縮寫）。

來源

2016-07-26 13:43:24

我懷疑這個區域是中國標準時間，而不是中央。 –

感謝@BasilBourque，你說得對，我只是好奇，想了解爲什麼CST有這麼多的時間:) – 2016-07-26 16:31:38

非常感謝你！ – finemi

中國標準時間（CST）的含義建議

的answer by Alfredo是正確的，但爲一個假設。這個問題的答案中提到中部標準時間，但該區域是背後 UTC（7或6小時），而在問題的數據是提前UTC的。所以我認爲CST這裏指的是China Standard Time，它比UTC早8。

這種混亂說明了爲什麼我們不應該使用這些3-4個字母的縮寫，如CST。它們不是真正的時區，不是標準化的，甚至不是獨一無二的（正如我們在這裏看到的那樣）。而是以continent/region的形式使用proper tz/IANA time zones。

java.time

的問題是使用舊的日期，時間類的。這些設計不佳且出了名的麻煩類已經被Java 8和後來的java.time框架所取代。

該字符串應該由Instant直接解析在UTC得到的值。

Instant instant = Instant.parse("2016-04-20T13:58:35.805Z");

呼叫toString來得到同樣的字符串返回的，按ISO 8601標準格式。

應用時區通過一個特定地區的wall-clock time的鏡頭，看看同一時刻。應用ZoneId以獲得ZonedDateTime對象。

對於America/Montreal的例子，掛鐘時間比UTC小四個小時，所以小時是09而不是13。

ZoneId zoneId = ZoneId.of("America/Montreal"); 
ZonedDateTime zdt = instant.atZone(zoneId);

2016-04-20T09：58：35.805-04：00 [美國/蒙特利爾]

兩者Instant和ZonedDateTime表示在時間軸上同一同步點。

來源

2016-07-26 16:08:24

謝謝！什麼是最好的解決辦法，當我使用solrj？我必須每次手動更改結果。我想要更改solrj的結果。例如，讓它返回DateTime或CST – finemi

使用solrj獲取8小時的日期差異

回答

中國標準時間（CST）的含義建議

java.time

相關問題