Parsen von Datums-mit Joda mit Zeitzone

Ich habe zwei timestamps, die beschreiben, auf den gleichen Zeitpunkt in zwei verschiedenen Formaten.

2010-10-03 18:58:07 und 2010-10-03T16:58:07.000+02:00.

Ich parse die Zeitstempel mit zwei verschiedenen Datums-formatter mit Joda-Time. Am Ende will ich zwei DateTime-Objekte, die gleich sind in Bezug auf die gleichen Augenblick der Zeit.

Den DateFormatter-bietet verschiedene Methoden zum Steuern der Zeitzonen und Orte, aber ich konnte es nicht zu funktionieren.

Dies ist der code, ich möchte arbeiten:

    final String date1 = "2010-10-03 18:58:07"; //Europe/Berlin local time
    final DateTimeFormatter formatter1 = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss");
    final DateTime dateTime1 = formatter1.parseDateTime(date1);

    final String date2 = "2010-10-03T16:58:07.000+02:00"; //Europe/Berlin local time with time zone
    final DateTimeFormatter formatter2 = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ss.SSSZ");
    final DateTime dateTime2 = formatter2.parseDateTime(date2);

    Assert.assertTrue(dateTime1.isEqual(dateTime2));

InformationsquelleAutor wilfried | 2011-01-07

  1. 7

    Wenn Ihr Standard-Zeit zome ist Europe/Berlin, 2010-10-03 18:58:07 entspricht 2010-10-03T16:58:07.000+00:00.

    Du wahrscheinlich missverstehen Sie die Zeitzone-Feld in der string-Darstellung. Ihre Zeitstempel 2010-10-03T16:58:07.000+02:00 bedeutet, dass "es ist 16:58:07 in einer Zeitzone mit +2 Stunde offset von GMT), oder in einer anderen Formulierung, "es ist jetzt 16:58:07 in Berlin". Ich gehe davon aus, dass Sie erwartet, dass es bedeutet, dass es 16:58:07 GMT?

    Sie haben eine Art "2010-10-03T16:58:07.000+02:00 bedeutet, dass es nicht 16:58:07 in einer Zeitzone mit +2 Stunde offset von GMT)". Es muss heißen: "2010-10-03T16:58:07.000+02:00 bedeutet, dass es 16:58:07 in einer Zeitzone mit +2 Stunde offset von der UTC -)"
    Ja, ich erwartet, dass es 16:58:07 GMT. Dann sieht es aus wie die timestamps sind einfach gebrochen. Dies sind die Zeitstempel von zwei verschiedenen log-Dateien von verschiedenen Servern. Und ich bin mir ziemlich sicher, dass Sie angeben, die das gleiche Ereignis. So dies waren meine Verwirrung kam.
    Sicher, ich schrieb ein bisschen zu schnell da.
    Es macht alles Sinn, wenn wir denken, der erste timestamp generierte in der Europa/Moskauer Zeitzone, die zweite in Europa/Berlin. Ich muss nur hinzufügen, diese auf der zweiten DateTimeFormatter: withZone(DateTimeZone.forID("Europe/Berlin")) und der test bestanden. Obwohl ich nicht weiß, wir haben die Server in Moskau. 😀
    Ich habe, um es in den ersten DateTimeFormatter, sorry.

    InformationsquelleAutor jarnbjo

  2. 4

    Ihre zwei Zeitstempel repräsentieren nicht die gleichen Augenblick in der Zeit (als jambjo schon bemerkte). Sehen Time zone offsets von UTC auf wikipedia.

    Siehe auch die parseDateTime Dokumentation auf, wie es funktioniert. Wenn Sie nicht bieten keine Zeit-zone, dann ist die Standard-Zeitzone angewendet werden (Berlin time zone UTC+2, wenn Sie da sind). Also:

    • 2010-10-03 18:58:07 wird 2010-10-03T18:58:07.000+02:00 (18:58 in Berlin mit offset von 2 Stunden zu UTC, das heißt, 16:58 UTC) wie erwartet.
    • 2010-10-03T16:58:07.000+02:00 bleibt wie es ist, denn es ist ein Zeit-zone angeboten (d.h. 16:58 in Berlin mit offset von 2 Stunden zu UTC, das heißt, 14:58 UTC)

    Hoffe, du hast die Idee. Sie müssen passen Sie die Zeiten mit der withZone Methode die gewünschten Ergebnisse zu erhalten.

    InformationsquelleAutor MicSim

  3. 1

    tl;dr

    Nutzung der modernen java.Zeit Klassen verdrängt Joda-Time. 

    LocalDateTime                                   //Represent a date and time-of-day without the context of a time zone or offset-from-UTC. *Not* a moment, *not* a point on the timeline.
.parse(                                         //Parse text into a date-time value.
    "2010-10-03 18:58:07".replace( " " , "T" )  //Replace SPACE in middle with a `T` to comply with ISO 8601 standard used by default in *java.time* when parsing/generating strings.
)                                               //Returns a `LocalDateTime` object.
.atZone(                                        //Assign the time zone we know for certain was intended for this input. 
    ZoneId.of( "Europe/Moscow" )                //Real time zones are named in `Continent/Region` format, never 2-4 letter codes such as CST, PST, IST, CEST, etc.
)                                               //Returns a `ZonedDateTime` object, a date with time-of-day and with a time zone assigned to determine a moment.
.toInstant()                                    //Adjust from time zone to UTC. 
.equals(
    OffsetDateTime                              //Represent a date and time-of-day with an offset-from-UTC but not a full time zone.
    .parse( "2010-10-03T16:58:07.000+02:00" )   //Parse a standard ISO 8601 string.
    .toInstant()                                //Adjust from offset to UTC (in other words, an offset of zero hours-minutes-seconds). 
)                                               //Returns `boolean`.

    wahr

    Details

    Den Antwort von jarnbjo ist richtig, dass Sie falsch verstanden, die Bedeutungen der offset von UTC und Zeitzone Werte.

    Nun im Jahr 2018, die Joda-Time Projekt ist im Wartungs-Modus. Das Projekt AUFTRAGGEBER Autor, Stephen Colebourne, ging auf gefunden JSR 310 und Autor seine Umsetzung, die java.Zeit Klassen fand in OpenJDK.

    Ersten Eingang

    Ihre Eingabe string 2010-10-03 18:58:07 ist fast in standard ISO 8601 - format. Zu erfüllen, ersetzen Sie das LEERZEICHEN in der Mitte mit einem T. 

    String input1 = "2010-10-03 18:58:07".replace( " " , "T" ) ;

    Diesem string fehlt jegliche Anzeige der Zeitzone oder der offset von UTC. So analysieren wie ein LocalDateTime.

    LocalDateTime ldt = LocalDateTime.parse( input1 ) ;

    Dieser Wert hat nicht repräsentieren einen moment, ist nicht einen Punkt auf der Zeitleiste. Ohne den Kontext einer zone oder ausgeglichen, es könnte einer von vielen Momenten in einem Bereich von etwa 26-27 Stunden, die Auswahl der Zeitzonen rund um den Globus.

    In Ihre Kommentare, die Sie enthüllt, dass offenbar wird, dass Eingangs-string gemeint war, stellen ein Datum und eine Uhrzeit in der Europe/Moscow Zeitzone. Damit wir zuordnen können, die zone zu ermitteln, einen moment, einen Punkt auf der Zeitleiste.

    ZoneId zMoscow = ZoneId.of( "Europe/Moscow" ) ;
ZonedDateTime zdtMoscow = ldt.atZone( zMoscow ) ;  //Determine a moment by assigning a time zone.

    zdtMoscow.toString(): 2010-10-03T18:58:07+04:00[Europa/Moskau]

    Zweiten Eingang

    Ihrem zweiten Eingang 2010-10-03T16:58:07.000+02:00kompatibel mit der Norm ISO 8601 - format.

    Dieser Eingang hat einen offset von der UTC zwei Stunden vor der UTC. Also diese Zeichenkette repräsentiert die Zeit-of-day-von 14:58:07 UTC.

    Können wir analysieren, wie ein OffsetDateTime Respekt vor den gegebenen offset.

    OffsetDateTime odt2 = OffsetDateTime.parse( "2010-10-03T16:58:07.000+02:00" ) ;

    odt2.toString(): 2010-10-03T16:58:07+02:00

    Vergleichen

    Tun, diese beiden Beiträge stellen den gleichen moment, den gleichen Punkt auf der Zeitachse?

    Einem Weg zu vergleichen ist, die durch die Anpassung zu UTC. Ein Instant ist immer in UTC, per definition.

    Tipp: Holen Sie sich die Gewohnheit des Denkens, der Arbeit, die Speicherung, den Austausch und die Protokollierung in UTC. Denke, von UTC als Die Eine Wahre Zeit.

    Instant instant1 = zdtMoscow.toInstant() ;  //Adjust from time zone to UTC.
Instant instant2 = odt2.toInstant() ;       //Adjust from offset to UTC.

boolean equality = instant1.equals( instant2 );

    Beim ausführen, sehen wir die Ergebnisse mit einem Z am Ende. Das heißt, UTC, und ist ausgesprochen Zulu. Und in der Tat sehen wir diese beiden Werte repräsentieren den gleichen moment, fast 3 Uhr in UTC.

    instant1.toString(): 2010-10-03T14:58:07Z

    instant2.toString(): 2010-10-03T14:58:07Z

    Gleichheit: true

    Über java.Zeit

    Den java.Zeit framework ist in Java 8 und höher. Diese Klassen verdrängen die lästige alte Vermächtnis Datum-Zeit-Klassen wie java.util.Date, Calendar, & " = SimpleDateFormat.

    Den Joda-Time Projekt, jetzt in Wartungsmodus, rät der migration auf die java.Zeit Klassen.

    Um mehr zu erfahren, siehe die Oracle Tutorial. Und die Suche Stack Overflow für viele Beispiele und Erklärungen. Spezifikation JSR 310.

    Können Sie exchange java.Zeit Objekte direkt mit Ihrer Datenbank. Verwenden Sie eine JDBC-Treiber kompatibel mit JDBC 4.2 oder später. Keine Notwendigkeit für Streicher, keine Notwendigkeit für java.sql.* Klassen.

    Wo erhalten Sie die java.Zeit-Klassen?

    Den ThreeTen-Extra Projekt erweitert die java.mal mit zusätzlicher Klassen. Dieses Projekt ist ein Testgelände für mögliche künftige Erweiterungen zu java.Zeit. Sie finden möglicherweise einige nützliche Klassen, die hier wie Interval, YearWeek, YearQuarter, und mehr.

    InformationsquelleAutor Basil Bourque

  4. 0

    Hatte ich das gleiche Problem wie Sie und der beste Weg den ich gefunden ist, um die Daten analysieren.
    Ursprünglich hatte ich dieses format: 2018-01-22 09:25:14.000 +0000

    Einfach wählen Sie die Spalte aus, und klicken Sie auf "Text in Spalten" in der Data-Registerkarte.

    Ich verwendet, Getrennt mit Raum zu analysieren, dieses format in 3 verschiedenen Spalten.
    Also am Ende habe ich;

    Col 2018-01-22
    Col B 09:25:14.000
    Col C +0000

    Welche Spalte? Was ist tab? Denken Sie an Tabellen? Diese Frage ist über die Java-Programmierung.

    InformationsquelleAutor Mathieu Laporte

Schreibe einen Kommentar