Jag kom på att problemet berodde på min MySQL-servers time_zone inställningen sätts till SYSTEM (och mitt system är US Central). Laravel tillhandahåller tidsstämplar som redan har konverterats till UTC, men min databas tolkar dem som US Central på grund av time_zone miljö. Tiderna konverteras faktiskt igen internt av MySQL till en "riktig" UTC unix-tidsstämpelrepresentation (som kommer att vara felaktig eftersom den är förskjuten av tidszonen), även om de verkar vara UTC redan i varje fråga eftersom de också konverteras tillbaka till US Central igen för läsning ( Jag vet rätt).
På grund av detta, klockan 20:00:39 (20:00) lokal tid är mina Laravel UTC-tidsstämplar 02:00:39. MySQL tolkar dessa tider som US Central-tid, och eftersom tiden är mellan 02:00 och 03:00 (vilket är då klockorna hoppar framåt för US Central), är tiden ogiltig.
Den bästa lösningen för en Laravel-applikation är att tvinga alla databasanslutningar att använda en +00:00 tidszon (eller vad du nu har ställt in som applikationens tidszon i config/app.php ) så att det inte kommer att ske en sekundär konvertering. Detta kan göras i config/database.php :
'mysql' => [
// ...
'timezone' => '+00:00'
],
På så sätt är du inte utlämnad till din databasserver om den har en konfigurerad tidszon som skiljer sig från din Laravel-applikation. Det andra alternativet är att ändra databasens time_zone inställning, men då riskerar du fortfarande att buggen återkommer om du någon gång byter värd eller behöver bygga om servern av någon anledning (och inte konfigurerar tidszonen korrekt igen), eller påverkar andra databaser på servern.
Viktig anmärkning:Eftersom alla tidigare tidsstämplar kompenserades internt av MySQL från den konfigurerade tidszonen till UTC unix-tidsstämplar (som återigen var fel eftersom posterna redan var UTC) kan det vara nödvändigt att köra en datamigrering för att korrigera gamla tidsstämplar. Jag har inte undersökt ytterligare eftersom det för min ansökan inte spelar någon roll om de gamla tidsstämplarna var fel med några timmar.