Te doy la bienvenida a nuestra página, en este sitio vas a hallar la solucíon que necesitas.
Solución:
Los tipos “Local …” deliberadamente no tienen concepto de zona horaria. Asi lo hacen no representan un momento en la línea de tiempo. A LocalDateTime representa un rango vago de momentos posibles, pero no tiene un significado real hasta que se asigna un desplazamiento o zona horaria. Eso significa aplicar un ZoneId conseguir un ZonedDateTime.
Por ejemplo, para decir que la Navidad de este año comienza en el primer momento del 25 de diciembre, decimos:
LocalDateTime ldt = LocalDateTime.of( 2017 , 12 , 25 , 0 , 0 , 0 , 0 );
Pero ese golpe de la medianoche ocurre antes en el este que en el oeste.
Es por eso que el departamento de Logística de los elfos traza la ruta de Santa comenzando en Kiribati en el Pacífico, la primera zona horaria del mundo 14 horas antes de UTC. Después de entregar allí, enrutan a Santa hacia el oeste a lugares como Nueva Zelanda para su medianoche más tarde. Luego a Asia para su medianoche más tarde. Luego India, y así sucesivamente, llegando a Europa para su medianoche varias horas más tarde, y luego a la costa este de América del Norte para su medianoche unas horas más tarde. Todos estos lugares experimentaron que mismoLocalDateTime en diferentes momentos, cada entrega representada por un diferenteZonedDateTime objeto.
Entonces…
- Si desea grabar el concepto de Navidad a partir de la medianoche del día 25, utilice un
LocalDateTimey escribir en una columna de la base de datos de tipoTIMESTAMP WITHOUT TIME ZONE. - Si desea registrar el momento exacto de cada entrega que hace Santa, use un
ZonedDateTimey escribir en una columna de la base de datos de tipoTIMESTAMP WITH TIME ZONE.
Acerca de esa segunda viñeta, tenga en cuenta que casi todos los sistemas de base de datos usarán la información de la zona para ajustar la fecha y hora a UTC y almacenar ese valor UTC. Algunos también guardan la información de la zona, pero algunos, como Postgres, descartan la información de la zona después de usarla para ajustar a UTC. Por tanto, “con zona horaria” es un nombre poco apropiado, que en realidad significa “con el respeto para zona horaria ”. Si le interesa recordar esa zona original, es posible que deba guardar su nombre en una columna separada al lado.
Otra razón para usar Local… tipos es para citas futuras. Los políticos disfrutan cambiando con frecuencia las zonas horarias de su jurisdicción. Les gusta adoptar el horario de verano (DST). Me gusta cambiar las fechas de sus cambios de horario de verano. Les gusta dejar de adoptar el horario de verano. Les gusta redefinir sus zonas horarias, cambiando los límites. Les gusta redefinir su compensación de UTC a veces en cantidades como 15 minutos. Y rara vez avisan con anticipación, y hacen cambios con tan solo uno o dos meses de advertencia.
Por lo tanto, para programar una cita de control médico para el próximo año o en seis meses, no se puede predecir la definición de la zona horaria. Entonces, si desea una cita para las 9 a. M., Debe usar un LocalTime o LocalDateTime registrado en una columna de la base de datos de tipo TIMESTAMP WITHOUT TIME ZONE. De lo contrario, esa cita de las 9 a. M., Si se divide en zonas donde se pospone el cambio de horario de verano, puede aparecer como 8 a. M. O 10 a. M.
Al generar una programación proyectada, puede aplicar una zona horaria (ZoneId) a esos valores “locales” (sin zona) para crear ZonedDateTime objetos. Pero no confíe en los que están demasiado lejos en el tiempo cuando los políticos pueden arruinar su significado al cambiar la (s) zona (s).
Sugerencia: estos cambios frecuentes en el horario de verano y las zonas horarias significan que debe mantener su zona horaria tzdata base de datos actualizada. Hay un tzdata en su sistema operativo host, su JVM y quizás en su sistema de base de datos como Postgres. Los tres deben actualizarse con frecuencia. A veces, las zonas cambian más rápido que los ciclos de actualización planificados de esos productos como Turquía el año pasado y decidieron permanecer en horario de verano con solo varias semanas de anticipación. Por lo tanto, es posible que ocasionalmente deba actualizar manualmente esos archivos tzdata. Oracle proporciona una herramienta para actualizar los tzdata de sus implementaciones de Java.
La mejor práctica general para manejar los momentos exactos es rastrearlos en UTC. Aplique una zona horaria solo cuando sea necesario, como en la presentación a un usuario donde esperan ver valores en su propia zona horaria local. En java.time, el Instant la clase representa un momento en la línea de tiempo. En UTC con una resolución de nanosegundos.
Instant instant = Instant.now() ; // Current moment on the timeline in UTC.
ZonedDateTime zdt = instant.atZone( z ) ; // Assign a time zone to view the same moment through the lens of a particular region’s wall-clock time.
Instant instant = zdt.toInstant(); // revert back to UTC, stripping away the time zone. But still the same moment in the timeline.
Por cierto, los controladores que cumplen con JDBC 4.2 y versiones posteriores pueden tratar directamente con los tipos java.time a través de:
PreparedStatement::setObjectResultSet::getObject
Curiosamente, la especificación JDBC 4.2 no requiere soporte para los dos java.time tipos: Instant Y ZonedDateTime. La especificación requiere soporte para OffsetDateTime. Para que pueda convertir fácilmente de un lado a otro.
Evite los viejos tipos de datos heredados como java.util.Date y java.sql.Timestamp cuando sea posible. Están mal diseñados, confusos y defectuosos.
Comprenda que estos cuatro son representaciones de un momento en la línea de tiempo en UTC:
- Moderno
java.time.Instantjava.time.OffsetDateTimecon un desplazamiento asignado deZoneOffset.UTC
- Legado
java.util.Datejava.sql.Timestamp
Si desea un valor de solo fecha sin hora del día y sin zona horaria, use java.time.LocalDate. Esta clase suplanta java.sql.Date.
En cuanto a las bases de datos específicas, tenga en cuenta que el estándar SQL apenas toca el tema de los tipos de fecha y hora y su manejo. Además, las distintas bases de datos varían ampliamente, y realmente me refiero ampliamente, en su apoyo a las funciones de fecha y hora. Algunos prácticamente no tienen soporte. Algunos mezclan tipos estándar de SQL con tipos propietarios que son anteriores a los tipos estándar o están pensados como alternativas a los tipos estándar. Además, los controladores JDBC difieren en su comportamiento al calcular los valores de fecha y hora hacia / desde la base de datos. Asegúrese de estudiar la documentación y practicar, practicar, practicar.
¿O debería usar Instant de Java 8? Si usa Instant, ¿existirá la posibilidad de almacenar solo la parte de la fecha, sin tiempo?
Instant debería ser adecuado para la mayoría de las operaciones.
Agregar hibernate-java8 para pom.xml para admitir la API de tiempo de Java 8:
org.hibernate
hibernate-java8
$version.hibernate
Entonces puedes usar LocalDate o LocalDateTime o Instant para los campos de entidad de Hibernate. Necesitas eliminar @Temporal(TemporalType.TIMESTAMP).
Mi requisito es almacenar todas las fechas y fechas y horas en la zona horaria UTC en la base de datos. Estoy usando LocalDate y LocalDateTime de Java 8 en mis entidades de Hibernate.
¿Es correcto ya que LocalDate y LocalDateTime no tienen una zona horaria asociada?
Puede establecer la zona horaria predeterminada de la JVM en algún lugar de un código de configuración:
@PostConstruct
void setUTCTimezone()
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Luego operará la hora UTC en su código.
Para usar los tipos de fecha de Java 8 en DTO, debe agregar Jsr310JpaConverters:
org.springframework.boot
spring-boot-starter-data-jpa
Y:
@EntityScan(basePackageClasses = Application.class, Jsr310JpaConverters.class )
SpringBootApplication
public class Application …
Mas opciones:
- Forzar la zona horaria de Java como GMT / UTC
- ¿Cómo configurar la zona horaria de Java?
- Cómo configurar correctamente una zona horaria de JVM