Il tuo cliente getDate() il codice sembra corretto per quanto va. Penso che tu debba anche ottenere il driver MySQL Connector/J JDBC per trattare le date memorizzate nella tabella come date UTC, per evitare una conversione spuria del fuso orario. Ciò significa impostare il fuso orario effettivo del server, oltre al fuso orario della sessione client e al Calendario utilizzati per JDBC getTimestamp chiama come stai facendo.
Dai un'occhiata ai valori che hai ottenuto nella tua asserzione non riuscita e in quale direzione si trova l'errore:
expected:<Thu Apr 16 11:30:30 BST 2015> but was:<Thu Apr 16 10:30:30 BST 2015>
Quello che hai ricevuto erano le 10:30 BST, che sono le 9:30 GMT. Ciò è coerente con il database che tratta le 10:30 nella tabella come valore BST e lo converte in modo spurio in GMT per te, prima di analizzarlo come data GMT. Questa è la direzione opposta di un valore GMT convertito in modo spurio in BST.
Questo potrebbe essere un problema specifico di JDBC, poiché JDBC richiede che gli orari vengano convertiti nella zona locale. (Dove l'API C di MySQL non lo fa, probabilmente perché i tipi temporali classici di C non sono consapevoli della zona come lo sono quelli di Java.) E ha bisogno di sapere da quale zona sta convertendo da , anche. Il TIMESTAMP di MySQL il tipo viene sempre memorizzato come UTC. Ma questo non è indicato per DATETIME genere. penso ciò implica che MySQL interpreterà DATETIME i valori delle colonne sono nel fuso orario del server. Che hai menzionato come impostato su BST, e questo è coerente con la direzione dello spostamento mostrato nel tuo messaggio di errore di asserzione.
Il time_zone La variabile di sessione che hai impostato sta dicendo al server MySQL qual è il fuso orario della tua macchina client, ma non influisce su ciò che il server pensa che sia il proprio fuso orario. Questo può essere ignorato con serverTimezone Proprietà di connessione JDBC
. Sulla tua connessione, imposta il serverTimezone in UTC e assicurati che useLegacyDatetimeCode è spento. (E guarda le altre proprietà relative alla zona se ciò non funziona.) Verifica se le tue date vengono visualizzate come UTC con gli stessi valori dei campi del calendario del database.
Tieni presente che questo cambierà l'interpretazione di altri DATETIME valori nel tuo database:ora sembreranno tutte date UTC (nel contesto della tua connessione JDBC). Se è corretto dipenderà da come sono stati popolati inizialmente. Sebbene il tuo codice client avrà il comportamento desiderato, non so se questo sistema nel suo insieme può essere fatto in modo che si comporti in modo completamente coerente senza impostare il fuso orario del server su UTC a livello di server. Fondamentalmente, se la sua zona non è impostata su UTC, non è completamente configurata per il comportamento che desideri e ti stai aggirando.
