Mysql
 sql >> Base de données >  >> RDS >> Mysql

Laravel SQLSTATE[22007] :format datetime invalide :1292 valeur datetime incorrecte :'2019-03-10 02:00:39' pour la colonne 'updated_at' (heure d'été ?)

J'ai compris que le problème était dû au time_zone de mon serveur MySQL le paramètre étant défini sur SYSTEM (et mon système est US Central). Laravel fournit des horodatages qui ont déjà été convertis en UTC, mais ma base de données les interprète comme US Central en raison du time_zone paramètre. Les temps sont en train d'être convertis encore en interne par MySQL à une "vraie" représentation d'horodatage UTC unix (qui sera incorrecte car elle est décalée par le fuseau horaire), même s'ils semblent déjà être UTC dans chaque requête car ils sont également reconvertis en US Central pour la lecture ( Je sais bien).

Pour cette raison, à 20:00:39 (20:00), heure locale, mes horodatages Laravel UTC sont 02:00:39. MySQL interprète ces heures comme l'heure du centre des États-Unis et, comme l'heure est comprise entre 02h00 et 03h00 (c'est-à-dire lorsque les horloges avancent pour le centre des États-Unis), l'heure n'est pas valide.

La meilleure solution pour une application Laravel est de forcer chaque connexion à la base de données à utiliser un +00:00 fuseau horaire (ou tout ce que vous avez défini comme fuseau horaire de l'application dans config/app.php ) afin qu'aucune conversion secondaire ne se produise. Cela peut être fait dans config/database.php :

'mysql' => [
    // ...

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

De cette façon, vous n'êtes pas à la merci de votre serveur de base de données s'il a un fuseau horaire configuré différent de votre application Laravel. L'autre option est de changer le time_zone de la base de données paramètre, mais vous risquez toujours que le bogue se reproduise si jamais vous changez d'hôte ou si vous devez reconstruire le serveur pour une raison quelconque (et ne configurez plus correctement le fuseau horaire), ou si vous affectez d'autres bases de données sur le serveur.

Remarque importante :étant donné que tous les horodatages précédents étaient décalés en interne par MySQL du fuseau horaire configuré vers les horodatages UTC unix (qui, encore une fois, étaient erronés car les enregistrements étaient déjà UTC), il pourrait être nécessaire d'exécuter une migration de données pour corriger le anciens horodatages. Je n'ai pas approfondi mes recherches car pour mon application, peu importe si les anciens horodatages étaient erronés de quelques heures.