sql >> Base de Datos >  >> RDS >> Mysql

Laravel SQLSTATE[22007]:Formato de fecha y hora no válido:1292 Valor de fecha y hora incorrecto:'2019-03-10 02:00:39' para la columna 'actualizado_en' (¿horario de verano?)

Descubrí que el problema se debía a la time_zone de mi servidor MySQL la configuración se establece en SYSTEM (y mi sistema es US Central). Laravel proporciona marcas de tiempo que ya se convirtieron a UTC, pero mi base de datos las interpreta como US Central debido a la time_zone entorno. Los tiempos en realidad se están convirtiendo nuevamente internamente por MySQL a una representación de marca de tiempo UTC unix "real" (que será incorrecta porque está compensada por la zona horaria), a pesar de que parecen ser UTC ya en cada consulta porque también se vuelven a convertir a US Central nuevamente para lectura ( Lo sé bien).

Debido a esto, a las 20:00:39 (8:00 p. m.) hora local, mis marcas de tiempo UTC de Laravel son 02:00:39. MySQL interpreta estas horas como la hora central de EE. UU., y debido a que la hora es entre las 02:00 y las 03:00 (que es cuando los relojes saltan hacia adelante para el centro de EE. UU.), la hora no es válida.

La mejor solución para una aplicación Laravel es obligar a cada conexión de base de datos a usar un +00:00 zona horaria (o lo que haya establecido como la zona horaria de la aplicación en config/app.php ) para que no se produzca una conversión secundaria. Esto se puede hacer en config/database.php :

'mysql' => [
    // ...

    'timezone'  => '+00:00'
],

De esta manera, no está a merced de su servidor de base de datos si tiene una zona horaria configurada que es diferente de su aplicación Laravel. La otra opción es cambiar la time_zone de la base de datos configuración, pero aún corre el riesgo de que el error se repita si alguna vez cambia de host o necesita reconstruir el servidor por cualquier motivo (y no configura la zona horaria correctamente de nuevo), o si afecta a otras bases de datos en el servidor.

Nota importante:Dado que MySQL compensaba internamente todas las marcas de tiempo anteriores de la zona horaria configurada a las marcas de tiempo UTC de Unix (que, de nuevo, eran incorrectas porque los registros ya eran UTC), podría ser necesario ejecutar una migración de datos para corregir el marcas de tiempo antiguas. No he investigado más porque para mi aplicación no importa si las marcas de tiempo anteriores eran incorrectas por algunas horas.