Ottenere "unixtime" in Java

258

Date.getTime () restituisce millisecondi dal 1 ° gennaio 1970. Unixtime è secondi dal 1 ° gennaio 1970. Di solito non codice in Java, ma sto lavorando su alcune correzioni di bug. Io ho:

Date now = new Date();      
Long longTime = new Long(now.getTime()/1000);
return longTime.intValue();

C'è un modo migliore per ottenere unixtime in Java?

java unix-timestamp

— Gary Richardson
fonte

Da quando lo hai lanciato su un int, hai introdotto il problema dell'anno 2038 (l'equivalente di Y2K per Unix). Questo è quando l'epoca di Unix raggiunge i 2 miliardi e passa al negativo. La correzione è passare a Unix a 64 bit. L'equivalente Java è di lasciarlo a lungo.

— John M,

Sì, ne sono consapevole. Il codice con cui si interfaccia si aspetta un int a 32 bit per unixtime.

— Gary Richardson,

158

Il 2038 arriverà presto.

— Pacerier,

Esiste un nome o uno standard appropriato per currentTimeMillis? Tendo a riferirmi nella mia documentazione come la versione in millisecondi del tempo UNIX.

— Tom,

Se vuoi che il tuo software sopravviva all'overflow, usa long, no int. Non c'è davvero alcun motivo per usare intun timestamp, a meno che tu non stia usando una granularità diversa come 1 secondo = 4 secondi ecc. O questo, o nascondi il tuo codice in modo che le generazioni future non possano vedere quanto sei incompetente.

— bryc,

Risposte:

475

Evita la creazione dell'oggetto Date con System.currentTimeMillis () . Una divisione per 1000 ti porta in epoca Unix.

Come accennato in un commento, in genere si desidera un long primitivo (long-l-long) non un oggetto boxed long (L-maiuscolo) per il tipo della variabile unixTime.

long unixTime = System.currentTimeMillis() / 1000L;

— John M
fonte

Considera anche l'utilizzo di Long primitivo anziché l'autoboxing su Long, a meno che tu non voglia gestire il numero come un oggetto (come metterlo in una raccolta), evita di nuovo la creazione di oggetti non necessari

— brabster

L'int Java a 32 bit corrisponde alle piattaforme a 32 bit (e al problema dell'anno 2038). Le piattaforme a 64 bit utilizzano un tipo di dati time_t più grande. Java schivò quel proiettile usando un long come il ritorno per System.currentTimeMillis (). Se ti converti in int, stai reintroducendo il problema dell'anno 2038. Vedi en.wikipedia.org/wiki/Year_2038_problem#Solutions

— John M

Penso che ti sbagli su un punto: non c'è differenza tra una "L" minuscola e una maiuscola quando li usi in letterali numerici come questo. docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.1

— matt

La discussione sulla capitalizzazione (chiarita sopra) riguardava il tipo di dati. Istanza di classe "long" vs "java.lang.Long" primitiva. Stai parlando della lettera del suffisso sul letterale lungo, che concordo può essere in maiuscolo o minuscolo. Sebbene la "l" minuscola assomigli molto alla cifra "1", quindi è molto più leggibile usare la "L" maiuscola.

— John M,

Fai clic sul collegamento alla documentazione. Il ritorno è definito come numero di millisecondi dall'1 / 1/1970 nel fuso orario UTC. Vuoi fusi orari? Guarda java.util.Calendar.

— John M,

273

Java 8 ha aggiunto una nuova API per lavorare con date e orari. Con Java 8 puoi usare

import java.time.Instant
...
long unixTimestamp = Instant.now().getEpochSecond();

Instant.now()restituisce un istante che rappresenta l'ora corrente del sistema. Con getEpochSecond()te ottieni i secondi di epoca (tempo unix) dal Instant.

— Micha
fonte

Qual'è la differenza tra Instant.now().getEpochSecond(), new Date().getTime()eSystem.currentTimeMillis()

— SohamC

Una differenza è che il primo è in secondi mentre gli ultimi due sono in millisecondi. Potrebbero essercene o meno altri.

— super_aardvark,

import java.time.Instantse sei in Scala

— akauppi

Controlla anche questo sito per una descrizione dettagliata ... Mi è piaciuto .. currentTimeMillis

— Subroto

Nota che non puoi utilizzare questo metodo con livelli API Android precedenti.

— Ali Nadalizadeh,