Umgang mit Zeitzonen mit Java

Bevor es auf das Thema wächst

Beim Umgang mit Zeitzonen mit java.util.Date in Java ist es meines Erachtens üblich, dass Datum und Uhrzeit die verstrichene Zeit (Millisekunden) ab der Epochenzeit und die von GMT zu verwaltende Zeitzone sind. Hier nehmen wir an, dass Datum, Uhrzeit und Zeitzone aus irgendeinem Grund getrennt bleiben. Zum Beispiel sieht es so aus

Wenn dies in System.out.println usw. angezeigt wird, fühlt sich der Wert des Datumstyps seltsam an, wie unten gezeigt. Mit anderen Worten, ich möchte, dass 15:00 Uhr Zeit für Australien / Sydney ist, aber aus irgendeinem Grund ist es eine lokale Zeitzone. Es ist wie es ist.

Thu Dec 01 15:00:00 JST 2016

sun.util.calendar.ZoneInfo[id="Asia/Tokyo",offset=32400000,dstSavings=0,useDaylight=false,transitions=10,lastRule=null]

Außerdem ** Wenn Sie die hier durchgeführte Konvertierung verwenden, wird ein Fehler ausgeführt. Andererseits erreichen Sie diese Logik als Lehrer nicht. ** Wenn Sie eine Lösung finden, werde ich sie erneut veröffentlichen. Ich bin mir nicht sicher, ob die Situation vermieden wird.

Hauptthema

Wie auch immer, ich denke darüber nach, wie ich es als korrekte Daten behalten kann, wenn die obige Situation eintritt. Das Vermeiden solcher Situationen kann die beste Lösung sein.

Für Java 8 oder früher

Es ist ein wenig kniffliger Code. Es ist eine sorgfältige Maßnahme, es in eine Zeichenfolge umzuwandeln.

TimezoneConversion.java

    static Date convertWithBeforeJava7(Date dateTime, TimeZone timeZone) throws ParseException {
        String format = "yyyy/MM/dd HH:mm:ss.SSS";
        SimpleDateFormat local = new SimpleDateFormat(format);
        SimpleDateFormat convert = new SimpleDateFormat(format);
        convert.setTimeZone(timeZone);
        return convert.parse(local.format(dateTime));
    }

Java8

Ich kann mich nicht daran gewöhnen, aber ich habe es auch in Java 8-Klassen versucht. Es ist irgendwie erfrischend, aber ich habe auch das Gefühl, dass ich mir die Mühe machen werde, zum Datumstyp zurückzukehren.

Testergebnisse

Ich habe zwei Arten von Tests durchgeführt. Die Eingabe ist wie folgt.

Umweltbedingung

Eingang

Bitte beachten Sie, dass dies kein ausreichender Test ist. Das Ergebnis ist wie folgt.

java.lang.AssertionError: It would be same date
Expected: is <Sun Oct 02 17:00:00 EST 2016>
     but: was <Sun Oct 02 18:00:00 EST 2016>

	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at com.nekoscape.java.sample.TimezoneConversionTest.convertWithOtherTimezone_test_for_Java8Method(TimezoneConversionTest.java:76)
(Kürzung)

java.lang.AssertionError: It would be same date
Expected: is <Sun Oct 02 17:00:00 EST 2016>
     but: was <Sun Oct 02 18:00:00 EST 2016>

	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at com.nekoscape.java.sample.TimezoneConversionTest.convertWithOtherTimezone_test_for_beforeJava7Method(TimezoneConversionTest.java:62)
(Kürzung)

Process finished with exit code -1

Zwei Tests sind fehlgeschlagen. Beides tritt auf, wenn Sie Amerika / Montreal angeben, das nicht die lokale Zeitzone ist. Was ist los?

Das Fazit ist, dass diese Logik jetzt Probleme hat, wenn die lokale Zeitzone Sommerzeit ist (Sommerzeit). 2016-10-02 02:00 als Datum und Uhrzeit angegeben ist das Startdatum und die Startzeit der Sommerzeit von Australien / Sydney. Wenn es daher als Datumstyp aus einer Zeichenfolge beibehalten wird, bedeutet dies bereits 2016-10-02 03:00. Infolgedessen tritt eine Stunde Konvertierungsfehler auf.

Wie eingangs erwähnt, handelt es sich um einen Fehler. Ich habe es nicht gelöst. Bitte kopieren Sie nicht, auch wenn Sie einen Fehler machen. Die Quelle befindet sich unten, damit Sie sie ausprobieren können. Quellcode: Zeitzonenumwandlung