Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Laravel SQLSTATE [22007]:formato de data e hora inválido:1292 Valor de data e hora incorreto:'2019-03-10 02:00:39' para a coluna 'updated_at' (horário de verão?)


Eu descobri que o problema era devido ao time_zone do meu servidor MySQL configuração sendo definida como SYSTEM (e meu sistema é US Central). O Laravel está fornecendo timestamps que já foram convertidos para UTC, mas meu banco de dados está interpretando-os como US Central devido ao time_zone contexto. Os horários estão sendo convertidos novamente internamente pelo MySQL para uma representação de timestamp unix "real" UTC (o que será incorreto porque é compensado pelo fuso horário), mesmo que pareçam ser UTC já em todas as consultas porque também são convertidos novamente para US Central novamente para leitura ( Eu sei direito).

Por causa disso, às 20:00:39 (20:00) hora local, meus timestamps Laravel UTC são 02:00:39. O MySQL interpreta esses horários como a hora Central dos EUA e, como a hora está entre 02:00 e 03:00 (que é quando os relógios avançam para a Central dos EUA), a hora é inválida.

A melhor solução para um aplicativo Laravel é forçar cada conexão de banco de dados a usar um +00:00 fuso horário (ou o que você definiu como fuso horário do aplicativo em config/app.php ) para que não ocorra uma conversão secundária. Isso pode ser feito em config/database.php :
'mysql' => [
    // ...

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

Dessa forma, você não fica à mercê do seu servidor de banco de dados se ele tiver um fuso horário configurado diferente do seu aplicativo Laravel. A outra opção é alterar o time_zone do banco de dados configuração, mas você ainda corre o risco de o bug se repetir se você alterar os hosts ou precisar reconstruir o servidor por qualquer motivo (e não configurar o fuso horário corretamente novamente) ou afetar outros bancos de dados no servidor.

Nota importante:Como todos os timestamps anteriores estavam sendo deslocados internamente pelo MySQL do fuso horário configurado para timestamps unix UTC (que, novamente, estavam errados porque os registros já eram UTC) pode ser necessário executar uma migração de dados para corrigir o carimbos de data e hora antigos. Não investiguei mais porque, para minha aplicação, não importa se os carimbos de data e hora antigos estavam errados por algumas horas.