Converter data dd/mm/aaaa para o MySQL com DateTime::createFromFormat

strtotime('31/08/2026') devolve false, e você só descobre isso no INSERT. Com barra o PHP lê a data no formato americano, tenta o mês 31 e desiste. O false vira string vazia no bind e o MySQL 8, com o strict mode que já vem ligado, derruba a query com Incorrect date value.

O formato tem que ser explícito

Diga ao PHP qual é a ordem dos campos e confira o resultado antes de confiar nele:

$entrada = '31/08/2026';
$data    = DateTimeImmutable::createFromFormat('!d/m/Y', $entrada);
$erros   = DateTimeImmutable::getLastErrors();

if ($data === false || ($erros !== false && $erros['warning_count'] + $erros['error_count'] > 0)) {
    throw new InvalidArgumentException('Data inválida: ' . $entrada);
}

$stmt = $pdo->prepare('INSERT INTO agenda (dia) VALUES (?)');
$stmt->execute([$data->format('Y-m-d')]); // 2026-08-31

A exclamação na frente do formato zera hora, minuto e segundo. Sem ela o objeto herda a hora do relógio, e a comparação com uma coluna DATETIME passa a depender do minuto em que o script rodou.

A armadilha do 31 de fevereiro

Só testar $data === false não basta. Com 31/02/2026 o PHP monta o objeto assim mesmo e rola a data para 03/03/2026, registrando um aviso em vez de falhar. É por isso que o getLastErrors() entra na conta.

Repare no !== false do exemplo: desde o PHP 8.2 o getLastErrors() devolve false quando a análise saiu limpa, no lugar do array de contadores zerados de antigamente. Código velho que lê $erros['warning_count'] direto solta Trying to access array offset on value of type bool no PHP 8.3 e ainda deixa a data errada passar.

Deixe a conversão numa função única do projeto e chame ela em toda entrada de data. Validar no JavaScript ajuda o usuário; quem defende o banco é essa checagem no servidor.