JSR 310 :: System.currentTimeMillis() vs Instant.toEpochMilli() :: Fuseau horaire

Pourriez vous s'il vous plaît jeter une certaine lumière sur la façon d'obtenir correcte époque le temps en millisecondes pour un fuseau horaire par défaut du système et compte tenu de fuseau horaire.

Donné

1. Fuseau horaire: GMT+3

2. L'extrait de code suivant:

import java.time.*;

public class Main {        
    public static void main(String[] args) {
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.UTC)
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(LocalDateTime
            .now()
            .atZone(ZoneOffset.of("+3"))
            .toInstant()
            .toEpochMilli()
        );
        System.out.println(System.currentTimeMillis());
    }
}

3. Sortie:

1444158955508
1444148155508
1444148155508

4. JavaDoc pour Système.currentTimeMillis() qui indique que la valeur retournée sera la différence, mesurée en millisecondes, entre l'heure actuelle et à minuit, le 1er janvier 1970 UTC.

Alors, pourquoi

  1. la sortie de la LocalDateTime à GMT+3 est le même que celui de System.currentTimeMillis(), bien que les docs pour la System.currentTimeMillis() mention UTC?
  2. la sortie de la LocalDateTime à UTC diffère de System.currentTimeMillis(), bien que les docs pour la System.currentTimeMillis() mention UTC?
InformationsquelleAutor szhem | 2015-10-06
  1. 32

    Les deux System.currentTimeMillis() et Instant.toEpochMilli() retourne le nombre de millisecondes écoulées depuis l'époque Unix. Ce n'est pas "dans" un moment particulier de la zone, bien que l'époque Unix est normalement exprimée comme "minuit le 1er janvier 1970 UTC". Mais un instant est un instant dans le temps, et c'est la même quel fuseau horaire vous êtes - mais il faudra réfléchir à une autre heure locale.

    La sortie de LocalDateTime.atZone(UTC) diffère parce que vous êtes en train de dire "Prendre la date et l'heure locales, et de la convertir en un instant comme si elle était dans le fuseau horaire UTC", même si, quand vous avez créé qui LocalDateTime vous n'avez donc implicitement à l'UTC+3 fuseau horaire... c'est pourquoi il est "mauvais".

    LocalDateTime.now() prend la date et l'heure locales dans le système de fuseau horaire par défaut. Donc, si votre fuseau horaire est UTC+3, le courant instantané dans le temps est 2015-10-06T16:57:00Z, puis LocalDateTime.now() sera de retour .2015-10-06T19:57:00. Disons que localNow...

    Donc localNow.atZone(ZoneOffset.of("+3")) sera de retour d'une ZonedDateTime représentant 2015-10-06T19:57:00+03 - en d'autres termes, la même date/heure, mais "savoir" qu'il est 3 heures à l'avance de l'heure UTC... donc toInstant() sera de retour une Instant représentant 2015-10-06T16:57:00Z. La Great - nous en avons encore la date/heure actuelle.

    Mais localNow.atZone(ZoneOffset.UTC) sera de retour d'une ZonedDateTime représentant 2015-10-06T19:57:00Z - en d'autres termes, la même date/heure, mais la "pensée", qu'il est déjà l'heure UTC... donc toInstant() sera de retour une Instant représentant 2015-10-06T19:57:00Z.. ce qui n'est pas à l'heure actuelle à tous (c'est dans trois heures).

    • Je voudrais ajouter un humble commentaire sur le dessus de l'excellente réponse de Jon. LocalDateTime.maintenant().atZone(Écartfuseau.UTC) est un appel de la conversion à ZonedDateTime comme LocalDateTime ne dispose pas d'une zone. L'argument passé en atZone() la méthode doit être un original (par défaut dans cet exemple) fuseau horaire utilisé pour dériver LocalDateTime, pas le "à" de la zone de l'auteur vise sans doute à sortir parce que l'Instant n'ont pas de zone. Si l'auteur n'a pas de spécifier le Fuseau horaire: GMT+3, il serait difficile de résoudre la question.
    InformationsquelleAutor Jon Skeet
  2. 1

    Version courte:

    Il n'y a aucun moyen de calculer LocalDateTime -> Instant, vous devez spécifier un fuseau horaire.
    Avec un fuseau horaire, vous obtenez un ZonedDateTime et peut calculer ZonedDateTime -> Instant

    Instant == System.currentTimeMillis() si le fuseau horaire de la ZonedDateTime est égale à la valeur par défaut du système de fuseau horaire.

    Version longue:

    LocalDateTime est à l'heure votre horloge(en plus de l'information de date). Ce qui n'est pas assez si vous ne nous dites pas ce qui le fuseau horaire de votre sont. 13:00 heures à Tokyo n'est pas le même Instant que de 13:00 heures de Paris.

    Une fois que vous ajoutez un fuseau horaire de votre LocalDateTime vous obtenez un ZonedDateTime et on peut savoir à quel moment de temps vous êtes réellement. E. g. êtes-vous à 13:00 heures à Tokyo ou à Paris?

    Pour obtenir le bon Instant le fuseau horaire de la ZonedDateTime doit être correcte. Si elle est de 13:00 heures à Tokyo, mais vous prétendez que vous êtes à 13:00 heures de Paris, vous obtiendrez un mauvais Instantanée.

    LocalDateTime:

    Il ne peut pas représenter un instant sur la ligne sans informations supplémentaires, telles que le décalage de durée ou d'horaire.

    ZonedDateTime:

    Cette classe gère la conversion de l'heure locale de ligne de LocalDateTime pour l'instant le temps de ligne de l'Instant. La différence entre les deux lignes est le décalage par rapport à UTC/gmt, Greenwich, représenté par un Écartfuseau.

    Pour obtenir un Instant vous avez besoin de convertir LocalDateTime à ZonedDateTime premier. Si vous avez fait ceci correctement(en indiquant le bon fuseau horaire) votre Instant d'accord avec le Système.currentTimeMillis().

    Système.currentTimeMillis():

    la différence, mesurée en millisecondes, entre l'heure actuelle et à minuit, le 1er janvier 1970 UTC.

    1. la sortie de la LocalDateTime à GMT+3 est le même que celui de Système.currentTimeMillis(), bien que la documentation du Système.currentTimeMillis() fait mention de l'UTC?

    Si votre fuseau horaire est GMT+3 puis ZonedDateTime.toInstant() vous donnera le bon Instant et, par conséquent, d'accord avec Système.currentTimeMillis()

    1. la sortie de la LocalDateTime UTC diffère du Système.currentTimeMillis(), bien que la documentation du Système.currentTimeMillis() fait mention de l'UTC?

    Si votre fuseau horaire est pas UTC puis ZonedDateTime.toInstant() vous donnera une incorrect Instant.

    InformationsquelleAutor Roland