Un servidor con el reloj desviado produce errores que parecen cualquier cosa menos un reloj: certificados «todavía no válidos», accesos que fallan con la contraseña correcta, tareas programadas a la hora equivocada. Merece descartarlo pronto, porque cuesta una sola orden.

timedatectl

Active la sincronización

timedatectl set-ntp true
timedatectl show -p NTPSynchronized --value

Tres relojes, tres ajustes

  • El sistema: manténgalo en UTC. Así cada registro y cada marca guardada quedan sin ambigüedad.
  • PHP: date.timezone, que afecta a lo que imprime date() y a nada más.
  • MySQL: tiene su propio time_zone, que afecta a NOW() y a CURRENT_TIMESTAMP.
date
php -r 'echo date("Y-m-d H:i:s T"), PHP_EOL;'
mysql -e "SELECT NOW(), @@global.time_zone, @@session.time_zone;"
Si PHP escribe una marca en hora local y MySQL guarda en UTC, cada comparación se desvía justo ese desfase, y solo dos veces al año, cuando el desfase cambia, se da cuenta alguien. Guarde en UTC y convierta al mostrar.

Qué se rompe cuando el reloj va mal

  • El TLS. Un certificado válido desde mañana se rechaza hoy. El error del navegador nombra el certificado, no el reloj.
  • Los tokens y el doble factor. Un código TOTP se deriva de la hora; con más de treinta segundos de desvío, todos los códigos son incorrectos.
  • Las tareas programadas. Se ejecutan a la hora equivocada, o dos veces, o ninguna al cruzar un cambio.
  • Cruzar registros. Dos servidores separados por minutos no se pueden leer juntos en absoluto.
Ponga el sistema en UTC y no lo cambie nunca. Enseñe la hora local a la gente en el último momento posible: en el navegador, desde su propio reloj.