XMLGregorianCalendar a java.sql.Timestamp

StackOverflow https://stackoverflow.com//questions/12712676

Domanda

Sto lavorando con webservices, l'inserimento di record, che restituiscono un valore di timestamp in XMLGregorianCalendar tipo.Ho bisogno di trasformarlo in java.sql.Valore di Timestamp, in modo da utilizzare una funzione come questa.

public static java.sql.Timestamp getSqlTimeStamp(XMLGregorianCalendar xgc) {
    if (xgc == null) {
        return null;
    } else {
        return new Timestamp(xgc.toGregorianCalendar().getTime().getTime());
    }
}
Timestamp timestamp=getSqlTimeStamp(ExitInXMLGregor.getTimestamp());

Il mio problema è che nel server, il valore del timestamp quando inserisco un record, assomiglia a questo:2012-10-03T19:23:22.342+02:00

Ma quando faccio il mio tipo di conversione, di ottenere il valore del timestamp come questo:2012-10-03T17:23:22.342

Il tempo nel server (dove il webservice, si trova in 2h oltre la mia lingua, e per qualche ragione, ho ottenere il mio inserto locale del tempo, dopo trasformarlo.Il problema è che ho davvero bisogno di ottenere l'ora del server, causa nel DB, il valore del timestamp partite con il server, e sto avendo problemi nell'operazione di aggiornamento, a causa dei diversi valori di timestamp.

Per favore, gradirei qualsiasi tipo di aiuto.grazie!

Edit:Ho un po ' di trovare una soluzione, ma non è esattamente quello di cui ho bisogno.Quando ho convertito il mio timestamp in java.sql.Formato Timestamp in XMLGregorian ho l'impostazione del fuso orario del server (setTimeZone(Fuso orario.getTimeZone("GMT+02:00"))).Questo funziona, ma è lontano dalla soluzione ideale (potrebbe accadere che il fuso orario o anche il server cambia) sarebbe bello sapere a questo punto il fuso orario del server dinamicamente, ma non so come...

public static XMLGregorianCalendar getXMLGregorianCalendar(Timestamp timestamp)
        throws BaseException {
    try {
        GregorianCalendar gc = new GregorianCalendar();
        gc.setTimeZone(TimeZone.getTimeZone("GMT+02:00"));
        gc.setTimeInMillis(timestamp.getTime());
        return DatatypeFactory.newInstance().newXMLGregorianCalendar(gc);
    } catch (DatatypeConfigurationException ex) {
        throw new BaseException(ex);
    }
}
È stato utile?

Soluzione

Sospetto che il timestamp specifichi il tempo corretto, non viene visualizzato solo con il fuso orario giusto. 2012-10-03t17: 23: 22.342 è la stessa del 2012-10-03T19: 23: 22.342 + 02: 00, assumendo il fuso orario (nascosto) del primo è +00: 00.

Altri suggerimenti

tl;dr

  • Entrambe le stringhe rappresentano stesso momento, semplicemente regolato ad un fuso orario pur non riuscendo a notare la offset-da-UTC.
  • Evitare tale confusione da sempre tra l'offset e la zona di info in tali stringhe.
  • L'uso moderno java.tempo classi di soppiantare il fastidioso classi precedenti.(Instant, non Timestamp)

Codice di esempio.

myPreparedStatement.setObject( 
    … , 
    myXMLGregorianCalendar  // If forced to work with a `javax.xml.datatype.XMLGregorianCalendar` object rather than a modern java.time class…
    .toGregorianCalendar()  // …convert to a `java.util.GregorianCalendar`, and then…
    .toZonedDateTime()      // …convert to modern `java.time.ZonedDateTime` class.
    .toInstant()            // Adjust to UTC by extracting an `Instant` object.
)

Il recupero da un database, come JDBC 4.2 e versioni successive.

Instant instant = myResultSet.getObject( … , Instant.class ) ;

java.tempo

Come corretto accettato Risposta da Robert Tupelo-Schneck dice, sembra che tutto è bene in che entrambe le stringhe rappresentano stesso momento, ma regolato in un fuso orario diverso, con un offset diverso-da-UTC.Il problema è che una di quelle due stringhe manca un indicatore della sua offset-da-UTC.

Tale omissione è una cattiva pratica come si crea questa confusione.Sempre includere l'offset-da-UTC meno che non sia assolutamente certo che il contesto rende l'offset/zona chiari.

Lavoro UTC

Lavoro in UTC evita questo tipo di confusione.Generalmente migliori di lavoro, negozio, di scambio e di data-i valori di ora in ora UTC.Regolare dall'UTC per un fuso orario solo per la presentazione all'utente o dove richiesto dalla logica di business.

Inoltre, si utilizza terribilmente fastidioso vecchie classi sono ora soppiantato dal java.tempo classi.Convertire il vostro XMLGregorianCalendar per java.time.ZonedDateTime.

ZonedDateTime zdt = myXMLGregorianCalendar.toGregorianCalendar().toZonedDateTime() ;

Regolare a UTC per l'estrazione di un Instant oggetto. 

Instant instant = zdt.toInstant() ;

Come di JDBC 4.2 e versioni successive, è possibile scambiare direttamente java.tempo gli oggetti con il database.Non c'è bisogno di usare sempre il legacy java.sql.Timestamp classe di nuovo.

myPreparedStatement.setObject( … , instant ) ;

Recupero:

Instant instant = myResultSet.getObject( … , Instant.class ) ;

Regolare dall'UTC per qualche momento particolare zona se si desidera visualizzare stesso momento utilizzando l'orologio da parete tempo utilizzato da persone di una particolare regione.

ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;

La conversione

Se si deve interfacciarsi con qualche vecchio codice che richiedono un java.sql.Timestamp, è possibile convertire back-e-indietro con java.time.Instant.Chiamata di nuovi metodi di conversione aggiunto delle vecchie classi.

java.sql.Timestamp ts = java.sql.Timestamp.from( instant ) ;

Andando nella direzione opposta.

Instant instant = ts.toInstant() ;

Vedi anche la mia Risposta a una simile Domanda.

Circa java.tempo

Il java.tempo quadro è costruito in Java 8 e versioni successive.Queste classi soppiantare il vecchio fastidioso legacy data di classi a tempo come java.util.Date, Calendar, & SimpleDateFormat.

Il Joda Tempo il progetto, ora in modalità di manutenzione, consigli di migrazione per il java.tempo classi.

Per saperne di più, vedere il Oracle Tutorial.E di ricerca di Overflow dello Stack per molti esempi e spiegazioni.Specifica JSR 310.

Si può scambiare java.tempo gli oggetti direttamente con il database.Utilizzare un Driver JDBC compatibile con JDBC 4.2 o più tardi.Nessuna necessità per le stringhe, non c'è bisogno per java.sql.* classi.

Dove ottenere il java.classi a tempo?

Il ThreeTen-Extra il progetto si estende java.ora con le classi aggiuntive.Questo progetto è un terreno di prova per eventuali future integrazioni di java.tempo.Si possono trovare alcune classi utili come l' Interval, YearWeek, YearQuarter, e più.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top