Verwenden Sie solrj, um den Datumsunterschied von 8 Stunden zu erhalten

Question

Es gibt eine Daten in meinem Solr:Using the Solr Administration User Interface, die ModifyTime ist "2016-04-20T13: 58: 35.805Z".

Mit solrj: enter image description here, die modifyTime ist "Mi 20. April 21.58.35 CST 2016".

Ich benutze solr6. Warum?

Answer 1

modifyTime Datenformat von User Interface Solr Verwaltung kommt, ist UTC, können Sie es durch die Z am Ende des Datetime-Zeichenfolge verstehen kann, was darauf hinweist, dass diese Zeichenfolge Darstellung des Datums in UTC ist.

2016-04-20T13:58:35.805Z 

Auf der anderen Seite, modifyTime von Datenformat kommt, ist CST - ZentralChina Standard Time, die es in Ihrem Fall scheint + 8 Stunden.

Wed Apr 20 21:58:35 CST 2016 

Dies geschieht aufgrund eines Java ärgerlich und schlecht Funktion, wo die java.util.Date keine Zeitzone hat noch es ist toString Methode der aktuellen Standard-Zeitzone des JVM gilt.

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

EDIT

Dank @BasilBourque für den Vorschlag über die Bedeutung von CST (Zeitzone Abkürzung)

Answer 2

China Standard Time (CST)

Die answer by Alfredo ist richtig, aber für eine Annahme. Diese Antwort erwähnt Central Standard Time, aber diese Zone ist hinter UTC (7 oder 6 Stunden), während die Daten in der Frage voraus von UTC ist. Also nehme ich an CST hier bezieht sich auf China Standard Time, die 8 vor UTC ist.

Diese Verwirrung zeigt, warum sollten wir nie diese 3-4 Buchstaben-Abkürzungen wie CST verwenden. Sie sind keine echten Zeitzonen, nicht standardisiert und nicht einmal einzigartig (wie wir hier sehen). Verwenden Sie stattdessen proper tz/IANA time zones in Form von continent/region.

java.time

Das Problem ist die Verwendung der alten Datum Zeitklassen. Diese schlecht entworfenen und notorisch lästigen Klassen wurden in Java 8 und später durch das java.time-Framework ersetzt.

Diese Zeichenfolge sollte direkt von Instant analysiert werden, um einen Wert in UTC zu erhalten.

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

Anruf toString die gleiche Art von String zurück, formatiert entsprechend dem ISO 8601 Standard.

eine Zeitzone Wenden Sie den gleichen Moment durch die Linse eines bestimmten Ortes der wall-clock time zu sehen. Wenden Sie eine ZoneId an, um ein Objekt ZonedDateTime zu erhalten.

Für das Beispiel America/Montreal ist die Wanduhrzeit vier Stunden hinter UTC, also ist die Stunde 09 statt 13.

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

2016-04-20T09: 58: 35,805 bis 04: 00 [America/Montreal]

Sowohl die Instant und die ZonedDateTime stellen den gleichen gleichzeitigen Punkt auf der Zeitachse.