114 votes

System.currentTimeMillis() renvoie-t-il l'heure UTC ?

Je veux obtenir l'heure UTC actuelle en millisecondes. J'ai fait des recherches sur Google et j'ai obtenu quelques réponses selon lesquelles System.currentTimeMillis() renvoie l'heure UTC, mais ce n'est pas le cas. Si je fais ce qui suit :

long t1 = System.currentTimeMillis();
long t2 = new Date().getTime();
long t3 = Calendar.getInstance().getTimeInMillis();

Les trois temps sont presque identiques (la différence est en milli secondes en raison des appels).

t1 = 1372060916
t2 = 1372060917
t3 = 1372060918

et cette heure n'est pas l'heure UTC mais plutôt l'heure de mon fuseau horaire. Comment puis-je obtenir l'heure UTC actuelle dans Android ?

5 votes

Renvoie l'heure actuelle du système en millisecondes depuis le 1er janvier 1970 00:00:00 UTC

2 votes

0 votes

C'est la question. Qu'est-ce qu'il retourne ? l'heure UTC ou il ajuste le fuseau horaire ? s'il retourne l'heure UTC, alors t1 et t2, t3 ne devrait pas être le même que t2 et t3 retourne l'heure de votre fuseau horaire.

159voto

Jon Skeet Points 692016

Les trois lignes que vous avez montrées donneront le nombre de millisecondes depuis l'époque unix, qui est un point fixe dans le temps, non affecté par votre fuseau horaire local.

Vous dites "cette heure n'est pas l'heure UTC" - je soupçonne que vous avez en fait fait un diagnostic incorrect. Je vous suggère d'utiliser epochconverter.com pour cela. Par exemple, dans votre exemple :

1372060916 = Mon, 24 Jun 2013 08:01:56 GMT

Nous ne savons pas quand vous avez généré cette valeur, mais à moins que ce ne soit en fait à 8h01 UTC, c'est un problème avec l'horloge de votre système.

Ni l'un ni l'autre System.currentTimeMillis ni la valeur dans un Date sont eux-mêmes affectés par le fuseau horaire. Cependant, vous devez savoir que Date.toString() fait utilisent le fuseau horaire local, ce qui induit en erreur de nombreux développeurs qui pensent qu'une Date est intrinsèquement associé à un fuseau horaire - il ne l'est pas, c'est juste un instant dans le temps, sans fuseau horaire associé ni même système de calendrier.

6 votes

En gros, cela signifie que cette fonction renvoie la même valeur si elle est appelée au même moment depuis des fuseaux horaires différents, quelle que soit l'horloge de l'hôte, n'est-ce pas ?

29 votes

Cela me fait souhaiter que le monde adopte (puisse adopter) un seul fuseau horaire. Qui se soucie de savoir si le chiffre sur l'horloge est 00:00 ou 08:00 lorsque la grande chose brillante apparaît dans le ciel ? Les innombrables heures de temps productif gaspillées pour cette relique historique me font bouillir le sang...

0 votes

À cet égard, il convient de noter que l'appel sous-jacent à la fonction d'horloge du système d'exploitation présente une "dérive" documentée de plusieurs millisecondes. Java dispose d'un "timer haute performance" si l'intention est d'obtenir une durée très précise d'une opération (chronométrage du début et de la fin d'une tâche, le delta étant le temps écoulé). Voir : [docs.oracle.com/javase/7/docs/api/java/lang/](https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime())

2voto

jlhonora Points 5280

Je peux confirmer que les trois appels pourrait dépendent de l'heure locale, en considérant l'époque, et non le Date.toString() ou toute autre méthode similaire. Je les ai vus dépendre de l'heure locale sur des appareils spécifiques fonctionnant sous Android 2.3. Je ne les ai pas testés avec d'autres appareils et versions d'Android. Dans ce cas, l'heure locale a été réglée manuellement.

La seule façon fiable d'obtenir une heure UTC indépendante est de demander une mise à jour de la localisation en utilisant la fonction GPS_PROVIDER . Le site getTime() valeur d'un emplacement récupéré à partir de NETWORK_PROVIDER dépend également de l'heure locale. Une autre option consiste à envoyer un ping à un serveur qui renvoie un timestamp UTC, par exemple.

Donc, ce que je fais est le suivant :

public static String getUTCstring(Location location) {
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
    String date = sdf.format(new Date(location.getTime()));
    // Append the string "UTC" to the date
    if(!date.contains("UTC")) {
        date += " UTC";
    }
    return date;
}

3 votes

System.currentTimeMillis() renvoie une valeur basée sur l'UTC. La "précision" ou l'exactitude de l'horloge du système d'exploitation, bien qu'elle affecte certainement le résultat, n'est en aucun cas liée à la valeur du fuseau horaire du système ou de l'environnement Java.

0 votes

@DarrellTeague J'insiste, j'ai vu des valeurs différentes dans un appareil Huawei spécifique. Donc non, il ne renvoie pas toujours l'heure UTC correcte (sans tenir compte des différences de précision).

0 votes

La question de l'OP concernait l'utilisation d'un fuseau horaire dans une classe Java. Il ne s'agissait pas d'une question de matériel ou d'exactitude de la valeur temporelle renvoyée. En termes simples, la JVM obtient son heure à partir de l'"horloge système" (abstraite) du système d'exploitation (dont le fonctionnement varie d'un système d'exploitation à l'autre). Voir aussi : drdobbs.com/embedded-systems/ et les implémentations "C" sur les systèmes d'exploitation chemie.fu-berlin.de/chemnet/use/info/libc/libc_17.html

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X