Obtenir «unixtime» en Java

258

Date.getTime () renvoie des millisecondes depuis le 1er janvier 1970. Unixtime est en secondes depuis le 1er janvier 1970. Je ne code généralement pas en java, mais je travaille sur quelques corrections de bogues. J'ai:

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

Existe-t-il un meilleur moyen d'obtenir unixtime en Java?

java unix-timestamp Gary Richardson
la source
27
Puisque vous l'avez casté en entier, vous avez introduit le problème de l'année 2038 (l'équivalent de Y2K pour Unix). C'est alors que l'époque Unix atteint 2 milliards de dollars et passe au négatif. Le correctif consiste à passer à Unix 64 bits. L'équivalent Java est de le laisser aussi longtemps.
John M
1
Oui, j'en suis conscient. Le code avec lequel il s'interface attend un int de 32 bits pour unixtime.
Gary Richardson
158
2038 arrive bientôt.
Pacerier
Existe-t-il un nom propre ou une norme pour currentTimeMillis? J'ai tendance à y faire référence dans ma documentation comme la version milliseconde du temps UNIX.
Tom
1
Si vous voulez que votre logiciel survive à un débordement, n'utilisez longpas int. Il n'y a vraiment aucune raison d'utiliser intun horodatage, à moins que vous n'utilisiez une granularité différente comme 1 seconde = 4 secondes, etc.
bryc

Réponses:

475

Évitez la création d'objet Date avec System.currentTimeMillis () . Une division par 1000 vous amène à l'époque Unix.

Comme mentionné dans un commentaire, vous voulez généralement un objet long primitif (long minuscule-l) et non un objet encadré long (long L majuscule) pour le type de la variable unixTime.

long unixTime = System.currentTimeMillis() / 1000L;
John M
la source
3
Pensez également à utiliser la primitive long au lieu de l'autoboxing vers Long, à moins que vous ne vouliez gérer le nombre comme un objet (comme le mettre dans une collection), évite à nouveau la création inutile d'objets
brabster
9
Le Java 32 bits int correspond aux plates-formes 32 bits (et au problème de l'année 2038). Les plates-formes 64 bits utilisent un type de données time_t plus grand. Java a esquivé cette balle en utilisant un long comme retour pour System.currentTimeMillis (). Si vous vous convertissez en int, vous réintroduisez le problème de l'année 2038. Voir en.wikipedia.org/wiki/Year_2038_problem#Solutions
John M
1
Je pense que vous vous trompez sur un point: il n'y a pas de différence entre un "L" minuscule et un majuscule lorsque vous les utilisez dans des littéraux numériques comme celui-ci. docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.1
mat forsythe
5
La discussion sur la capitalisation (clarifiée ci-dessus) concernait le type de données. Instance de classe primitive "long" vs "java.lang.Long". Vous parlez de la lettre suffixe sur le long littéral, qui je conviens peut être en majuscule ou en minuscule. Bien que le "l" minuscule ressemble beaucoup au chiffre "1", il est donc beaucoup plus lisible d'utiliser le "L" majuscule.
John M
1
Cliquez sur le lien vers la documentation. Le retour est défini comme le nombre de millisecondes depuis le 1/1/1970 dans le fuseau horaire UTC. Vous voulez des fuseaux horaires? Regardez java.util.Calendar.
John M
274

Java 8 a ajouté une nouvelle API pour travailler avec les dates et les heures. Avec Java 8, vous pouvez utiliser

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

Instant.now()renvoie un instant qui représente l'heure actuelle du système. Avec getEpochSecond()vous obtenez les secondes d'époque (temps unix) du Instant.

micha
la source
4
Quelle est la différence entre Instant.now().getEpochSecond(), new Date().getTime()etSystem.currentTimeMillis()
SohamC
2
Une différence est que le premier est en secondes tandis que les deux derniers sont en millisecondes. Il peut y en avoir ou non.
super_aardvark
3
import java.time.Instantsi vous êtes à Scala
akauppi
4
Consultez également ce site pour une description détaillée ... J'ai bien
Subroto
1
Notez que vous ne pouvez pas utiliser cette méthode avec les anciens niveaux d'API Android.
Ali Nadalizadeh