Wie Joda-Time zu verwenden, mit java.sql.Timestamp

Question

Ich habe ein prepared statement

INSERT INTO mst(time) VALUES (?); 

, wo die Zeit vom Typ Timestamp in einer PostgreSQL Datenbank.
Ich füge ein Joda-TimeDateTime Objekt, oder ich sollte sagen, ich versuche zu. Ich kann keine Möglichkeit finden, das DateTime-Objekt in eine java.sql.Timestamp zu konvertieren. Ich habe die Dokumente von Joda-Time gelesen und sehe keinen Hinweis darauf.

Danke.

Answer 1

Sie können zuerst eine Joda DateTime in eine lange (Millis seit der Epoche) konvertieren und dann daraus einen Timestamp erstellen.

DateTime dateTime = new DateTime(); 
Timestamp timeStamp = new Timestamp(dateTime.getMillis()); 

Answer 2

Der DateTime-Konstruktor von JodaTime kann dies jetzt für Sie erledigen. (Ich bin nicht sicher, ob das wahr ist, wenn die Frage gestellt wurde, aber es ist ein Top-Google-Ergebnis so dass ich dachte ich eine neuere Lösung hinzufügen würde.)

Es gibt ein paar API-Optionen:

public DateTime(Object instant); 
public DateTime(Object instant, DateTimeZone zone); 

Beide Optionen akzeptieren java.sql.Timestamp, weil es java.util.Date erweitert, aber die Nanosekunden werden ignoriert (floored), da DateTime und Date nur eine Millisekunden-Auflösung * haben. Ohne eine bestimmte Zeitzone wird standardmäßig DateTimeZone.UTC verwendet.

< Didactic Modus >
"Auflösung" ist, wie viele Stellen vorgesehen sind. "Präzision" ist, wie genau die Darstellung ist. Zum Beispiel hat MSSQLs DateTime eine Millisekunden-Auflösung, aber nur eine 1/3 Sekunde Genauigkeit (DateTime2 hat eine variable Auflösung und höhere Genauigkeit).
</Didactic Modus >

UTC-Zeitstempel mit Millisekundenauflösung Beispiel:

new DateTime(resultSet.getTimestamp(1)); 

Wenn Sie TIMESTAMP WITH TIME ZONE in Ihrer Datenbank verwenden, dann können Sie nicht java.sql.Timestamp verwenden, da Es unterstützt keine Zeitzonen. Sie müssen ResultSet # getString verwenden und die Zeichenfolge analysieren.

Zeitstempel ohne Zeitzone mit dem zweiten Auflösung Beispiel **:

LocalDateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss") 
    .parseLocalDateTime(resultSet.getString(1)); 

UTC-Zeitstempel mit dem zweiten Resolution Beispiel **:

DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss") 
    .parseDateTime(resultSet.getString(1)); 

Zeitstempel mit Zeitzone (Offset-Format) mit dem zweiten Auflösung Beispiel **:

DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss Z") 
    .parseDateTime(resultSet.getString(1)); 

Bonus: DateTimeFormat # forPattern statisch ally cachiert Parser nach Muster, so dass Sie nicht müssen.

< Didactic Modus >
Generell empfehle ich einen String in Ihrem DBO-Modell, um mit Auflösung expliziten und vermeiden Zwischen Objekte erzeugen, zu machen. (Ist 2013-11-14 09:55:25 gleich dem 2013-11-14 09: 55: 25.000?) Ich versuche generell zwischen "Datenbankmodellobjekten" zu unterscheiden, die für Datenerhaltsprobleme optimiert sind, und "Businessmodellobjekten", die für die Verwendung auf Serviceebene mit einer dazwischenliegenden Transformations-/Mappingschicht optimiert sind. Ich finde, CRUD-basierte DAOs, die Geschäftsobjekte generieren, tendieren dazu, die Prioritäten zu verwechseln und für beide zu optimieren, indem sie Ausnahmen von unerwarteten Stellen wegen fehlender Randfälle werfen. Wenn Sie über eine explizite Transformationsebene verfügen, können Sie bei Bedarf auch eine Validierung hinzufügen, z. B. wenn Sie die Datenquelle nicht steuern. Die Trennung der Bedenken erleichtert auch das unabhängige Testen jeder Schicht.
</Didactic Modus >

* Wenn Sie Nanosekunde Auflösung in Ihrem Geschäftsmodell noch auflösen müssen Sie eine andere Bibliothek verwenden müssen.

** Zeitstempel String-Format kann zwischen den Datenbanken variieren, nicht sicher.