2016-02-03 11 views
80

Ho un'API esterna che mi restituisce le date come long s, rappresentate come millisecondi da Epoch.Come posso creare un LocalDate Java 8 da un lungo periodo Epoch in Milliseconds?

Con il vecchio stile API Java, vorrei semplicemente costruire un Date da esso con

Date myDate = new Date(startDateLong)

Qual è l'equivalente in Java 8 di LocalDate/LocalDateTime classi?

Sono interessato a convertire il punto nel tempo rappresentato dal long a LocalDate nel fuso orario locale corrente.

+4

bene bisogna iniziare a lavorare fuori quello fuso orario che ti interessano . Un valore "millisecondi da epoca" ti dà un istante di tempo ... che potrebbe riferirsi a date diverse in fusi orari diversi. Ricorda che 'java.util.Date' non è mai stato un appuntamento nel modo in cui' LocalDate' è - è stato anche un istante nel tempo. –

+2

Controlla questa domanda: http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate, che copre la conversione di 'java.util.Date' in' LocalDate' – hotzst

+1

Nota: questo Q & A è utile anche per coloro che cercano di convertire 'File.lastModified()' (epoch millis) in 'LocalDate (Time)'. – kevinarpe

risposta

150

Se si dispone dei millisecondi dal Epoch e vogliono convertirli in una data locale utilizzando l'attuale fuso orario locale, è possibile utilizzare

LocalDate date = 
    Instant.ofEpochMilli(longValue).atZone(ZoneId.systemDefault()).toLocalDate(); 

ma tenere presente che anche il fuso orario predefinito del sistema potrebbe cambiare, pertanto lo stesso valore long potrebbe produrre risultati diversi nelle esecuzioni successive, anche sulla stessa macchina.

Inoltre, tenere presente che LocalDate, a differenza di java.util.Date, rappresenta davvero una data, non una data e un'ora.

In caso contrario, è possibile utilizzare un LocalDateTime:

LocalDateTime date = 
    LocalDateTime.ofInstant(Instant.ofEpochMilli(longValue), ZoneId.systemDefault()); 
+0

+1 da parte mia per una spiegazione più dettagliata. A proposito, anche una zona non di sistema può cambiare (da tzupdater-tool o da jdk-change) e quindi produrre risultati diversi prima e dopo. –

+1

@Meno Hochschild: Non mi concentravo sui fusi orari codificati, ma piuttosto sul confronto con i fusi orari specificati dall'utente, lessi da un file di configurazione o da variabili di ambiente, in cui il programmatore presume naturalmente che possa cambiare. I fusi orari hardcoded sono in effetti molto simili al default del sistema; il programmatore è tentato di pensare che non stiano mai cambiando ... – Holger

15

Si può iniziare con Instant.ofEpochMilli(long):

LocalDate date = 
    Instant.ofEpochMilli(startDateLong) 
    .atZone(ZoneId.systemDefault()) 
    .toLocalDate(); 
+1

+1 per essere espliciti sul fuso orario. Se omesso, l'attuale fuso orario predefinito della JVM viene applicato implicitamente nel determinare la data. Per un dato momento la data varia in base al fuso orario in tutto il mondo, mentre un nuovo giorno sorge prima nell'est. –

0

Fusi orari e cose a parte, una semplice alternativa al new Date(startDateLong) potrebbe essere LocalDate.ofEpochDay(startDateLong/86400000L)

+3

Penso che dovresti almeno spiegare cosa rappresenta 86400000L. – BAER

+1

Ho pensato che era molto facile notare che è il numero di millisecondi in un giorno. –

+2

Per alcuni lo è, e ho pensato che solo quello avrebbe avuto senso, ma senza ricalcolare quanti ms al giorno ha davvero, non ne sarei sicuro. Solo parlando per me stesso, non conosco questo numero così bene da sapere automaticamente che cosa rappresenta. – BAER

Problemi correlati