Java 8 date-time: obtenir début de la journée de ZonedDateTime

Quelle est la différence entre ces:

zonedDateTime.truncatedTo(ChronoUnit.DAYS);

zonedDateTime.toLocalDate().atStartOfDay(zonedDateTime.getZone());

Aucune raison de préférer l'une contre l'autre?

Grâce

Ne pouvait pas mettre en place la méthode atStartOfDay() dans ZonedDataTime classe?

InformationsquelleAutor Nazaret K. | 2015-03-19

44

Mis à jour pour l'intérêt de la correction:

Dans la plupart des cas, oui le même, voir l'exemple suivant pour le Brésil lors du passage de l'hiver à l'heure d'été:
```
ZonedDateTime zdt = 
  ZonedDateTime.of(2015, 10, 18, 0, 30, 0, 0, 
    ZoneId.of("America/Sao_Paulo")); //switch to summer time
ZonedDateTime zdt1 = zdt.truncatedTo(ChronoUnit.DAYS);
ZonedDateTime zdt2 = zdt.toLocalDate().atStartOfDay(zdt.getZone());

System.out.println(zdt); //2015-10-18T01:30-02:00[America/Sao_Paulo]
System.out.println(zdt1); //2015-10-18T01:00-02:00[America/Sao_Paulo]
System.out.println(zdt2); //2015-10-18T01:00-02:00[America/Sao_Paulo]
```
Tronquer qui se passe sur le locale de la timeline. Si vous choisissez de JOURS, alors vous optez pour minuit. Selon javadoc la truncate()-méthode enfin convertit à la nouvelle ZonedDateTime et décale le temps de l'avant par la taille de l'écart (1 heure).

La conversion de la zdt premier à LocalDate (en coupant la partie du temps) et ensuite à la recherche de sa ZonedDateTime-partie dans le fuseau horaire est effectivement la même chose pour cette situation.

Cependant, pour le cas inverse de commutation de retour de l'heure d'été à l'heure d'hiver, il est une exception (merci beaucoup à @Austin qui a donné un contre-exemple). Le problème est en cours de chevauchement lors de décider qui offset à être utilisé. Habituellement, la classe ZonedDateTime est conçu et spécifié d'utiliser le décalage, voir aussi cet extrait de Javadoc:

De Chevauchements, de la stratégie générale est que si la date locale en temps
tombe au milieu d'un Chevauchement, le décalage sera
conservés. Si il n'y a pas de précédent de décalage, ou de l'offset est
pas valide, alors le plus tôt offset est utilisé, généralement "été" le temps.

Si la classe ZonedDateTime serait, par conséquent, de suivre sa propre spécification, les deux procédures serait encore une signification équivalente à:
```
zdt.truncatedTo(ChronoUnit.DAYS);
```
devrait être équivalente à
```
zdt.toLocalDate().atStartOfDay().atZone(zdt.getZone()).withEarlierOffsetAtOverlap();
```
Mais le comportement réel, selon l'exemple de @Austin et confirmé par mes propres tests est:
```
zdt.toLocalDate().atStartOfDay().atZone(zdt.getZone()).withLaterOffsetAtOverlap();
```
Ressemble à un caché d'une incohérence dans la classe ZonedDateTime, légèrement parlé. Si vous me demandez quelle méthode préférée, alors je préfère prôner la deuxième méthode, même si elle est beaucoup plus longue et nécessite plus de frappes. Mais il a le gros avantage d'être plus transparents sur ce qu'il fait. Une autre raison de préférer la seconde approche est la suivante:

Il vraiment obtient le PREMIER instant où le temps local est égal au début de la journée. Sinon, lors de l'utilisation de la première méthode, vous devez écrire:
```
zdt.truncatedTo(ChronoUnit.DAYS).withEarlierOffsetAtOverlap();
```
- Ce n'est pas toujours correcte! Voir ma réponse pour pourquoi pas.
- Votre réponse semble être plausible. Je vais examiner et de corriger ma réponse en conséquence.
InformationsquelleAutor Meno Hochschild
29

Elles sont légèrement différentes. Selon la documentation javadoc, truncatedTo() essaient de préserver le fuseau horaire dans le cas de chevauchement, mais atStartOfDay() trouverez la première occurrence de minuit.

Par exemple, Cuba revient de l'heure d'été à 1h du matin, pour retomber à 12h. Si vous commencez avec un temps après la transition, atStartOfDay() sera le retour de la première occurence de 12h, tandis que truncatedTo() sera de retour de la seconde occurence.
```
ZonedDateTime zdt = ZonedDateTime.of(2016, 11, 6, 2, 0, 0, 0, ZoneId.of("America/Havana"));
ZonedDateTime zdt1 = zdt.truncatedTo(ChronoUnit.DAYS);
ZonedDateTime zdt2 = zdt.toLocalDate().atStartOfDay(zdt.getZone());

System.out.println(zdt);  //2016-11-06T02:00-05:00[America/Havana]
System.out.println(zdt1); //2016-11-06T00:00-05:00[America/Havana]
System.out.println(zdt2); //2016-11-06T00:00-04:00[America/Havana]
```
- Merci beaucoup d'avoir trouvé un contre-exemple. Ont upvoted vous et également mis à jour ma réponse.
InformationsquelleAutor Austin
6

Note il y a aussi une autre façon de le faire:
```
zonedDateTime.with(LocalTime.MIN);
```
qui produit le même résultat que truncatedTo
- Comment va se comporter dans le cas où l'heure d'été (DST) commence à minuit, qui est, le jour commence à 01:00? En tout cas, le code ne peut pas exprimer le comportement souhaité dans ce cas.
- Il va se comporter comme il se doit - c'est à dire produira minuit 00:00 dans ce fuseau horaire (ce qui est le bon fuseau horaire de l'heure d'été) par exemple 2018-01-27T00:00+11:00[Australie/Sydney] vs 2018-06-27T00:00+10:00[Australie/Sydney], Vous obtiendrez le même résultat que tous les 3 méthodes - les 2 dans la question d'origine et cette version plus courte
- En fait, pour préciser, ce que l'on produit le même résultat que la ChronoUnit.JOURS version pour le cas de coin
InformationsquelleAutor nevster

Vous devez vous connecter pour publier un commentaire.