Actualmente estoy estudiando la API java.time y he notado que la mayoría de las clases (por ejemplo, LocalDate , OffsetDateTime ) en java.time implementan la interfaz TemporalAdjuster , pero ZonedDateTime no. Me preguntaba por qué este es el caso. ¿Por qué excluir ZonedDateTime de la implementación de la interfaz TemporalAdjuster ?
Un TemporalAdjuster cambia otro objeto temporal mediante el método TemporalAdjuster.adjustInto(Temporal) . La interfaz Temporal permite modificar los campos individuales a través de Temporal.with(TemporalField, long) .
LocalDate puede implementar TemporalAdjuster porque su estado consiste completamente en campos temporales (año, mes, día del mes). Como tal, la implementación en LocalDate.adjustInto(Temporal) puede llamar a Temporal.with(TemporalField, long) pasando el año, mes y día (en realidad usa ChronoField.EPOCH_DAY , que es una combinación de año, mes y día).
OffsetDateTime puede implementar TemporalAdjuster porque su estado también consta completamente de campos temporales (año, mes, día del mes, hora, minuto, segundo, nanosegundo y segundos de compensación). Por lo tanto, nuevamente la implementación en OffsetDateTime.adjustInto(Temporal) puede llamar a Temporal.with(TemporalField, long) pasando los campos uno por uno.
ZonedDateTime no puede implementar TemporalAdjuster porque su estado incluye un ZoneId , que no es un campo temporal, por lo que no se puede pasar a Temporal.with(TemporalField, long) . es decir. no es posible cambiar la zona horaria de una clase temporal a través de la interfaz Temporal .
Dado que ZonedDateTime incluye todos los campos de fecha y hora posibles, esta restricción tiene poco efecto en la práctica.