Skip to content

Datum einen Tag zurück nach Auswahl aus MySQL DB

Lösung:

Zuerst habe ich gelesen, dass Sie dies in Ihrem Fall nicht können, aber für andere Leser möchte ich sagen, dass die allgemeine Empfehlung lautet, alles in UTC auszuführen, zumindest wenn Sie mehr als eine Zeitzone umfassen. Das wäre also die beste Lösung für dein Problem gewesen.

Zweitens, wie sowohl ich als auch Gord Thompson in Kommentaren erwähnt haben, ist die zweitbeste Lösung, Daten so zu behandeln, wie LocalDate, nicht java.sql.Date. Während letzteres nur gibt vor keine Tageszeit zu haben, es gibt wirklich Designprobleme, die es schwierig machen, Ihr Problem zu lösen. EIN LocalDate Ja wirklich ist ein Datum ohne Tageszeit und ohne Zeitzone, also sollte eine Wette sein, die viel sicherer ist (außer dass Datenbanktreiber falsch in und von konvertieren) LocalDate gehört worden; Ich kreuze meine Finger; wieder alles in UTC laufen zu lassen, würde auch diese Fehler beseitigen). Bearbeiten: Angenommen, Sie können Ihre benutzerdefinierte JDBC-Bibliothek ändern, so erhalten Sie eine LocalDate von einem ResultSet:

    LocalDate correctDateDirectlyFromDatabase
            = yourResultSet.getObject("yourDateColumn", LocalDate.class);

Es erfordert mindestens JDBC 4.2, das haben Sie wahrscheinlich.

Wenn Ihnen keines der oben genannten Möglichkeiten zur Verfügung steht, können Sie das Falsche hier korrigieren Date hast du aus der Datenbank. Es ist ein bisschen ein Hack, aber wird funktionieren.

import java.sql.Date;

// …

    // Modern ID of the time zone previously known as US/Eastern
    ZoneId datebaseTimeZone = ZoneId.of("America/New_York");

    Date dateFromDatabase = new Date(TimeUnit.SECONDS.toMillis(1_550_034_000));
    System.out.println("Date as retrieved from database (or pretending): " + dateFromDatabase);

    long epochMillis = dateFromDatabase.getTime();
    ZonedDateTime dateTime = Instant.ofEpochMilli(epochMillis)
            .atZone(datebaseTimeZone);
    LocalDate realDate = dateTime.toLocalDate();
    // Sanity check
    if (! realDate.atStartOfDay(datebaseTimeZone).equals(dateTime)) {
        throw new IllegalStateException("Failed to convert date correctly from " + datebaseTimeZone + " time zone");
    }

    System.out.println("Date is " + realDate);

Als ich dies in der Zeitzone Amerika / Chicago ausgeführt habe, wurde Folgendes gedruckt:

Date as retrieved from database (or pretending): 2019-02-12
Date is 2019-02-13

Ich habe versucht, es in anderen Zeitzonen auszuführen. In einigen Zeitzonen wird die erste Zeile gedruckt 2019-02-12, in anderen 2019-02-13. Die letzte Zeile wird gedruckt 2019-02-13 in allen Zeitzonen habe ich es versucht.

Jetzt habe ich dir a . gegeben LocalDate. Das ist gut so, das sollten Sie in Ihrer Weiterverarbeitung nutzen wollen. Falls Sie eine benötigen java.sql.Date Konvertieren Sie für eine andere Legacy-API, die Sie noch nicht ändern möchten, wieder in a Korrekt java.sql.Date Hier entlang:

    Date oldfashionedJavaSqlDate = Date.valueOf(realDate);
    System.out.println("Date converted back to " + oldfashionedJavaSqlDate);

Datum zurück auf 2019-02-13 umgestellt

Und wenn ich richtig sage, erfordert es, dass niemand die Standardzeitzone Ihrer JVM manipuliert, was für jedes Programm, das in der JVM ausgeführt wird, einfach ist.

Verknüpfung: Oracle-Tutorial: Date Time erklärt die Verwendung von java.time.

ich benutze serverTimezone Einstellung, aber ich bin mir nicht sicher, ob der Wert die Zeitzone sein sollte, die die Datenbank verwendet, oder ob sie nur die Zeitzone der JVM / des Servers überschreibt, auf dem die Anwendung ausgeführt wird.

serverTimezone=America/Chicago bedeutet "interpretieren Sie die Ergebnisse vom Server, als ob der Server die America/Chicago Zeitzone unabhängig von der Standardzeitzone, für die der Server konfiguriert ist". Wenn Sie diese Einstellung in Ihrer Verbindungszeichenfolge verwenden, erhalten Sie Timestamp Werte umgerechnet in America/Chicago obwohl die Standardzeitzone für den Server anscheinend ist America/New_York.

Bevor Sie sich jedoch für diesen Ansatz entscheiden, sollten Sie sich vergewissern, dass der Server wirklich verwendet America/New_York (die vermutlich zwischen Eastern Standard Time und Eastern Daylight Time hin- und herschalten würde) und kein fester Offset wie UTC-5 (der immer auf "Eastern Standard Time" bleiben würde).

Click to rate this post!
[Total: 0 Average: 0]



Anderer Beitrag

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.