Un server con l'orologio andato alla deriva produce errori che sembrano tutto tranne un orologio: certificati "non ancora validi", accessi che falliscono con la password giusta, cron all'ora sbagliata. Conviene escluderlo presto, perché costa un solo comando.

timedatectl

Accenda la sincronizzazione

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

Tre orologi, tre impostazioni

  • Il sistema - lo tenga su UTC. Così ogni log e ogni timestamp salvato non lasciano dubbi.
  • PHP - date.timezone, che incide su ciò che stampa date() e su nient'altro.
  • MySQL - ha un suo time_zone, che incide su NOW() e 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;"
Se PHP scrive un timestamp in ora locale e MySQL lo conserva in UTC, ogni confronto è sfalsato di quello scarto - e se ne accorge qualcuno solo due volte l'anno, quando lo scarto cambia. Conservi in UTC, converta al momento di mostrare.

Che cosa si rompe quando l'orologio sbaglia

  • Il TLS. Un certificato valido da domani oggi viene rifiutato. L'errore del browser nomina il certificato, non l'orologio.
  • I token e il doppio fattore. Un codice TOTP deriva dall'ora; oltre trenta secondi di scarto e ogni codice è sbagliato.
  • Il cron. I lavori partono all'ora sbagliata, o due volte, o non partono affatto a cavallo di un cambio.
  • Incrociare i log. Due server distanti minuti non si possono proprio leggere insieme.
Imposti il sistema su UTC e non lo cambi mai. Mostri l'ora locale alle persone all'ultimo momento possibile - nel browser, dal loro stesso orologio.