Mi iscrivo al coro nel quale si consiglia di saltare le classi ormai da tempo obsolete Date, Calendar, SimpleDateFormat e amici. In particolare, evito di utilizzare i metodi e i costruttori obsoleti della classe Date, come il costruttore Date(String) utilizzato. Sono stati deprecati perché non funzionano in modo affidabile tra fusi orari, quindi non usarli. E sì, la maggior parte dei costruttori e dei metodi di quella classe sono deprecati.
Mentre al momento della domanda, Joda-Time era (da tutto ciò che so) un'alternativa chiaramente migliore, il tempo è passato di nuovo. Oggi Joda-Time è un progetto in gran parte finito, e i suoi sviluppatori raccomandano l'uso di java.time, la moderna API di data e ora Java, invece. Ti mostrerò come.
ZonedDateTime localTime = ZonedDateTime.now(ZoneId.systemDefault());
// Convert Local Time to UTC
OffsetDateTime gmtTime
= localTime.toOffsetDateTime().withOffsetSameInstant(ZoneOffset.UTC);
System.out.println("Local:" + localTime.toString()
+ " --> UTC time:" + gmtTime.toString());
// Reverse Convert UTC Time to Local time
localTime = gmtTime.atZoneSameInstant(ZoneId.systemDefault());
System.out.println("Local Time " + localTime.toString());
Per cominciare, si noti che non solo è il codice solo la metà il tempo come la tua, è anche più chiaro da leggere.
Sul mio computer le stampe codice:
Local:2017-09-02T07:25:46.211+02:00[Europe/Berlin] --> UTC time:2017-09-02T05:25:46.211Z
Local Time 2017-09-02T07:25:46.211+02:00[Europe/Berlin]
ho lasciato fuori i millisecondi dall'epoca. Puoi sempre prenderli da System.currentTimeMillis(); come nella tua domanda, e sono indipendenti dal fuso orario, quindi non li ho trovati interessanti qui.
Ho indugiato esitante il nome della variabile localTime. Penso che sia un buon nome. La moderna API ha una classe chiamata LocalTime, quindi l'utilizzo di tale nome, non solo in maiuscolo, per un oggetto che non ha il tipo LocalTime potrebbe confondere alcuni (uno LocalTime non contiene le informazioni sul fuso orario, che dobbiamo mantenere qui per essere in grado di effettuare la conversione corretta, ma tiene solo l'ora del giorno, non la data).
vostra conversione da ora locale di UTC non era corretto e impossibile
Il obsoleto Date classe non detiene alcuna informazioni sul fuso orario (si può dire che internamente usa sempre UTC), quindi non c'è nessuna tale cosa come convertire un Date da un fuso orario all'altro. Quando ho appena eseguito il codice sul mio computer, la prima linea è stampato, era:
Local:Sat Sep 02 07:25:45 CEST 2017,1504329945967 --> UTC time:Sat Sep 02 05:25:45 CEST 2017-1504322745000
07:25:45 CEST è corretto, naturalmente.L'ora UTC corretta sarebbe stata 05:25:45 UTC, ma si dice ancora CEST, che non è corretto.
Ora non avrai più bisogno della classe Date, :-) ma se mai dovessi andare, la lettura obbligata sarebbe All about java.util.Date sul blog di codifica di Jon Skeet.
Domanda: Posso utilizzare l'API moderna con la mia versione Java?
Se si utilizza almeno Java , è possibile.
- In Java 8 e versioni successive, la nuova API è integrata.
- In Java 6 e 7 ottengono the ThreeTen Backport, il backport delle nuove classi (ovvero ThreeTen per JSR-310, in cui la moderna API è stata definita per la prima volta).
- Su Android, utilizzare l'edizione Android di ThreeTen Backport. Si chiama ThreeTenABP, e penso che ci sia una spiegazione meravigliosa in this question: How to use ThreeTenABP in Android Project.
Una buona risposta! Tuttavia, invece di TimeZone.getDefault(). GetOffset (localTime.getTime()), ci dovrebbero essere TimeZone.getDefault(). GetOffset (gmtTime.getTimeInMillis()). In caso contrario, potresti riscontrare problemi con DaylightSaving se il tuo orario UTC è in inverno, ma il locale è in estate. – Dime
'new Date (stringa di stringhe)' deprecated :( –
sei un life saver T_T questo è l'unico modo per risolvere i conflitti di java.util.date (@temporal) e timestamp (postgresql) di GMT rispetto a UTC – Sarief