Un serveur d’hébergement tourne presque toujours à l’heure UTC, indépendamment de la localisation réelle des visiteurs du site ; il faut donc un réglage séparé pour que les dates de publication et les horaires affichés correspondent au fuseau attendu par l’équipe éditoriale.
Fonctionnement dans WordPress
Ce réglage est stocké sous deux formes distinctes en base : l’option timezone_string (par exemple Europe/Paris) ou, à défaut, l’option gmt_offset exprimée en heures par rapport à UTC. Depuis WordPress 5.3, la fonction wp_timezone() retourne un objet DateTimeZone cohérent quel que soit le format choisi, et current_time() permet d’obtenir l’heure locale ou UTC selon le second paramètre.
Exemple
$maintenant = current_time( 'mysql' ); // heure locale du site
$tz = wp_timezone(); // objet DateTimeZonePièges fréquents
Utiliser la fonction PHP native date() plutôt que current_time() ou wp_date() ignore ce réglage et renvoie l’heure du serveur, ce qui décale silencieusement les tâches planifiées et l’affichage des dates par rapport à ce qu’attend l’utilisateur configuré dans les réglages globaux.
Bon à savoir
Choisir une ville plutôt qu’un simple décalage horaire fixe présente un avantage concret : le passage à l’heure d’été ou d’hiver est géré automatiquement par la base de données de fuseaux du système, alors qu’un décalage en heures figé doit être ajusté manuellement deux fois par an.
Ce réglage influence aussi l’horodatage des articles à publication programmée : un article prévu à « 9h00 » doit se déclencher à 9h00 heure locale du site, ce qui exige que la tâche planifiée sous-jacente tienne compte du même fuseau que celui affiché dans l’éditeur.