Un serveur dont l'horloge a dérivé produit des erreurs qui ressemblent à tout sauf à une horloge : des certificats « pas encore valides », des connexions qui échouent avec le bon mot de passe, des tâches cron à la mauvaise heure. Cela vaut la peine de l'écarter tôt, car cela coûte une commande.

timedatectl

Activer la synchronisation

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

Trois horloges, trois réglages

  • Le système - gardez-le en UTC. Chaque journal et chaque horodatage enregistré devient alors sans ambiguïté.
  • PHP - date.timezone, qui touche ce qu'imprime date() et rien d'autre.
  • MySQL - a son propre time_zone, qui touche NOW() et 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 écrit un horodatage en heure locale et que MySQL stocke en UTC, chaque comparaison est décalée du même écart - et on ne s'en aperçoit que deux fois par an, quand cet écart change. Stockez en UTC, convertissez à l'affichage.

Ce qui casse quand l'horloge est fausse

  • Le TLS. Un certificat valide à partir de demain est refusé aujourd'hui. L'erreur du navigateur nomme le certificat, pas l'horloge.
  • Les jetons et la double authentification. Un code TOTP dérive de l'heure ; à plus de trente secondes près, tous les codes sont faux.
  • Cron. Les tâches tournent à la mauvaise heure, ou deux fois, ou pas du tout au moment d'un changement.
  • Le recoupement des journaux. Deux serveurs décalés de plusieurs minutes ne peuvent pas être lus ensemble du tout.
Mettez le système en UTC et n'y touchez plus jamais. Montrez l'heure locale aux gens au tout dernier moment - dans le navigateur, d'après leur propre horloge.