Así que sigamos adelante. La siguiente entidad después de la fecha es la hora del día, representada por la clase LocalTime . Un ejemplo clásico es representar el horario de apertura de una tienda, digamos de 7:00 a 23:00. Las tiendas abren a esta hora en todo el país, pero los horarios reales variarán según la zona horaria. LocalTime es una clase de valor que almacena solo la hora, sin una fecha o zona horaria asociada. Al sumar o restar un período de tiempo, se cortará a medianoche. Es decir, 20:00 más 6 horas son 2:00. Usar LocalTime es similar a LocalDate : LocalTime time = LocalTime.of(20, 30); int hour = date.getHour(); // 20 int minute = date.getMinute(); // 30 time = time.withSecond(6); // 20:30:06 time = time.plusMinutes(3); // 20:33:06 los modificadores pueden funcionar con LocalTime , pero las operaciones de tiempo generalmente no son tan complejas como para requerir modificadores.
Combinando fecha y hora
La siguiente clase que veremos es
LocalDateTime . Esta clase de valor es una combinación de
LocalDate y
LocalTime . Representa tanto la fecha como la hora, sin zona horaria.
LocalDateTime se puede crear directamente o combinando fecha y hora:
LocalDateTime dt1 = LocalDateTime.of(2014, Month.JUNE, 10, 20, 30); LocalDateTime dt2 = LocalDateTime.of(date, time); LocalDateTime dt3 = date.atTime(20, 30); LocalDateTime dt4 = date.atTime(time); la tercera y cuarta opciones utilizan el método
atTime() , que proporciona una forma flexible de combinar fecha y hora. La mayoría de las clases del sistema de fecha y hora tienen métodos "at" que se pueden usar al combinar su objeto con otro para crear uno más complejo. Los otros métodos de la clase
LocalDateTime son similares a los de
LocalDate y
LocalTime .
Patrones de nomenclatura de métodos similares hacen que la API sea más fácil de aprender . Esta tabla enumera todos los prefijos de métodos involucrados:
Instante
Cuando tratamos con fechas y horas, normalmente trabajamos con años, meses, días, horas, minutos, segundos. Sin embargo, este es sólo un modelo de tiempo que puede llamarse "humano". El segundo modelo comúnmente utilizado es el tiempo “máquina” o “continuo”. En este modelo, un punto en el eje del tiempo está representado por un número grande. Este enfoque simplifica los algoritmos de cálculo y se utiliza para almacenar el tiempo en el sistema operativo
Unix , donde el tiempo está representado por la cantidad de segundos que han pasado desde el 1 de enero de 1970. De manera similar, en
Java , el tiempo se almacena como el número de milisegundos que han pasado desde el 1 de enero de 1970. El enfoque automático para los cálculos de tiempo en
la API java.time lo proporciona la clase de valor
Instantáneo . Proporciona la capacidad de representar un punto en un eje de tiempo sin toda la información que lo acompaña, como la zona horaria. De hecho, esta clase contiene el número de nanosegundos que han transcurrido desde la medianoche del 1 de enero de 1970.
Instant start = Instant.now(); // произведем вычисления Instant end = Instant.now(); assert end.isAfter(start); //машина времени не сработала Normalmente, la clase
Instant se utiliza para almacenar y comparar puntos en el tiempo en los que necesita almacenar cuándo ocurrió algún evento pero no le importa la zona horaria en la que ocurrió. En la mayoría de los casos, es más interesante lo que no podemos hacer con la clase
Instantánea que lo que podemos hacer con ella. Por ejemplo, las siguientes líneas de código generarán excepciones:
instant.get(ChronoField.MONTH_OF_YEAR); instant.plus(6, ChronoUnit.YEARS); Las excepciones ocurren porque el objeto
instantáneo solo almacena la cantidad de nanosegundos y no brinda la capacidad de trabajar con unidades de tiempo que sean más útiles para los humanos. Para utilizar otras unidades de medida, debe especificar al menos una zona horaria.
Zonas horarias
El principio de las zonas horarias se desarrolló en Inglaterra cuando la invención de los ferrocarriles y las mejoras en otros medios de comunicación permitieron a las personas viajar distancias suficientes para que se notaran las diferencias en el tiempo solar. Hasta ese momento, cada pueblo y ciudad vivía según su propio tiempo, que generalmente se medía mediante un reloj de sol. La imagen muestra un ejemplo de las dificultades que esto generó: las manecillas rojas del reloj muestran la hora de Greenwich y las manecillas negras la hora local, que difiere en 10 minutos: se desarrolló el sistema de husos horarios que reemplazó la hora solar local
. Pero el hecho clave es que las zonas horarias las crean los políticos y, a menudo, se utilizan para demostrar control político sobre un área. Como cualquier política, las reglas relacionadas con las zonas horarias a menudo desafían la lógica. Y además, estas reglas pueden cambiar, y a menudo cambian, sin previo aviso. Las reglas de zona horaria son compiladas por un grupo internacional que publica la base de datos de zonas horarias
de la IANA . Contiene el identificador de cada región de la Tierra y el historial de cambios de zona horaria para ella. Los identificadores parecen
"Europa/Londres" o
"América/Nueva_York" . Antes de que se lanzara
la API java.time , se usaba la clase
TimeZone para representar una zona horaria . Ahora se utiliza
ZoneId en su lugar . Hay dos diferencias clave entre ellos. En primer lugar,
ZoneId es inmutable, lo que permite, entre otras cosas, almacenar objetos de esta clase en variables estáticas. En segundo lugar, las reglas en sí se almacenan en la clase
ZoneRules , y no en el propio
ZoneId , y para obtenerlas es necesario llamar al método
getRules() en el objeto de la clase
ZoneId . Una característica común de todas las zonas horarias es un desplazamiento fijo de
UTC/Greenwich . La mayoría de las veces se utiliza esto cuando se habla de diferencias horarias entre diferentes ciudades, como "Nueva York está 5 horas detrás de Londres". La clase
ZoneOffset , descendiente de
ZoneId , representa la diferencia horaria con el meridiano principal que pasa por Greenwich en Londres. Desde el punto de vista de un desarrollador, sería fantástico no tener que lidiar con zonas horarias y sus complejidades.
La API java.time le permite hacer esto siempre que sea posible. Siempre que sea posible, utilice las clases
LocalDate, LocalTime, LocalDateTime e
Instant . Cuando no pueda prescindir de zonas horarias, utilice la clase
ZonedDateTime . Clase
ZonedDateTimele permite convertir fechas y horas de unidades de medida humanas, que vemos en calendarios y relojes, a unidades de máquina. Como resultado, puede crear
un ZonedTimeDate desde
la clase Local o desde
la clase Instantánea :
ZoneId zone = ZoneId.of("Europe/Paris"); LocalDate date = LocalDate.of(2014, Month.JUNE, 10); ZonedDateTime zdt1 = date.atStartOfDay(zone); Instant instant = Instant.now(); ZonedDateTime zdt2 = instant.atZone(zone); una de las características más desagradables de las zonas horarias es el llamado horario de verano. Con el cambio de horario de verano hacia y desde Greenwich, la diferencia de zona horaria con Greenwich cambia dos veces (o más) al año, generalmente aumentando en la primavera y disminuyendo en el otoño. Cuando esto sucede, tenemos que cambiar todos los relojes de nuestra casa. En las clases
java.time , los datos de compensación se representan como
"transformaciones de compensación" . En primavera esto provoca un "intervalo" en el tiempo, cuando algunos valores de tiempo son imposibles, y en otoño, por el contrario, algunos valores de tiempo ocurren dos veces. Todo esto es compatible con la clase
ZonedDateTime a través de sus métodos de fábrica y métodos de conversión. Por ejemplo, al agregar un día se suma un día lógico, que puede estar representado por más o menos de 24 horas si cambiamos al horario de verano o viceversa. Del mismo modo, el método
atStartOfDay() se llama así porque no podemos garantizar que el día comience exactamente a medianoche; debemos tener en cuenta el intervalo de tiempo al cambiar al horario de verano. Y un último consejo respecto al horario de verano. Si desea demostrar que ha tenido en cuenta la superposición de tiempo durante la transición del verano al invierno (cuando el mismo valor de tiempo aparece dos veces), puede utilizar uno de dos métodos especiales diseñados para tales situaciones: Estos métodos devolverán el anterior o el posterior.
zdt = zdt.withEarlierOffsetAtOverlap(); zdt = zdt.withLaterOffsetAtOverlap(); valor, si el objeto queda atrapado en una superposición durante la transición del horario de verano al invierno. En todas las demás situaciones, los valores de retorno serán los mismos.
Intervalos de tiempo
Todas las clases que discutimos anteriormente funcionan como puntos en la línea de tiempo. Se necesitan dos clases de valores adicionales para representar intervalos de tiempo. La clase
Duración representa un período de tiempo, medido en segundos y nanosegundos. Por ejemplo, "23,6 segundos". La clase
Período representa un período de tiempo medido en años, meses y días. Por ejemplo: "3 años, 2 meses y 6 días". Estos intervalos se pueden sumar o restar a una fecha u hora:
Period sixMonths = Period.ofMonths(6); LocalDate date = LocalDate.now(); LocalDate future = date.plus(sixMonths);
Formateo y análisis
Un paquete completo está diseñado para formatear y mostrar fechas y horas:
java.time.format . El paquete gira en torno a la clase
DateTimeFormatter y su fábrica
DateTimeFormatterBuilder . Las formas más comunes de crear un formateador son mediante métodos estáticos y constantes en
DateTimeFormatter , que incluyen:
Constantes para formatos comunes descritos en ISO, como ISO_LOCAL_DATE.
Patrones identificados por letras, como ofPattern("dd/MM/uuuu").
Estilos localizados como ofLocalizedDate(FormatStyle.MEDIUM).
Una vez que haya creado un formateador, generalmente lo usa pasándolo al método de clase de fecha apropiado:
DateTimeFormatter f = DateTimeFormatter.ofPattern("dd/MM/uuuu"); LocalDate date = LocalDate.parse("24/06/2014", f); String str = date.format(f); de esta manera, el código responsable de formatear la salida de fecha se aísla en una clase separada. Si necesita especificar por separado la configuración regional para el formato de fecha, use el método de formateo
withLocale(Locale) . Las clases responsables del calendario, la zona horaria y la entrada/salida de números fraccionarios tienen métodos similares. Si necesita más opciones de ajuste, consulte la documentación de la clase
DateTimeFormatterBuilder , que le permite crear formateadores complejos paso a paso. También le permite configurar el análisis de texto que no distingue entre mayúsculas y minúsculas, ignorar algunos errores de análisis, establecer compensaciones y elementos opcionales.
Línea de fondo
La API java.time es un nuevo modelo integral para trabajar con fecha y hora en
Java SE 8 . Lleva las ideas e implementaciones de
Joda-Time al siguiente nivel y finalmente permite a los desarrolladores evitar el uso de
java.util.Date y
Calendar . ¡Ahora trabajar con fechas y horas puede ser divertido!
. Pero el hecho clave es que las zonas horarias las crean los políticos y, a menudo, se utilizan para demostrar control político sobre un área. Como cualquier política, las reglas relacionadas con las zonas horarias a menudo desafían la lógica. Y además, estas reglas pueden cambiar, y a menudo cambian, sin previo aviso. Las reglas de zona horaria son compiladas por un grupo internacional que publica la base de datos de zonas horarias
de la IANA . Contiene el identificador de cada región de la Tierra y el historial de cambios de zona horaria para ella. Los identificadores parecen
"Europa/Londres" o
"América/Nueva_York" . Antes de que se lanzara
la API java.time , se usaba la clase
TimeZone para representar una zona horaria . Ahora se utiliza
ZoneId en su lugar . Hay dos diferencias clave entre ellos. En primer lugar,
ZoneId es inmutable, lo que permite, entre otras cosas, almacenar objetos de esta clase en variables estáticas. En segundo lugar, las reglas en sí se almacenan en la clase
ZoneRules , y no en el propio
ZoneId , y para obtenerlas es necesario llamar al método
getRules() en el objeto de la clase
ZoneId . Una característica común de todas las zonas horarias es un desplazamiento fijo de
UTC/Greenwich . La mayoría de las veces se utiliza esto cuando se habla de diferencias horarias entre diferentes ciudades, como "Nueva York está 5 horas detrás de Londres". La clase
ZoneOffset , descendiente de
ZoneId , representa la diferencia horaria con el meridiano principal que pasa por Greenwich en Londres. Desde el punto de vista de un desarrollador, sería fantástico no tener que lidiar con zonas horarias y sus complejidades.
La API java.time le permite hacer esto siempre que sea posible. Siempre que sea posible, utilice las clases
LocalDate, LocalTime, LocalDateTime e
Instant . Cuando no pueda prescindir de zonas horarias, utilice la clase
ZonedDateTime . Clase
ZonedDateTimele permite convertir fechas y horas de unidades de medida humanas, que vemos en calendarios y relojes, a unidades de máquina. Como resultado, puede crear
un ZonedTimeDate desde
la clase Local o desde
la clase Instantánea :
GO TO FULL VERSION