L’écran Réglages > Général propose deux façons de définir le fuseau horaire d’un site : sélectionner une ville dans une liste, ou choisir directement un décalage UTC numérique. En base de données, ce choix se traduit par deux options distinctes, timezone_string et gmt_offset, dont une seule est réellement renseignée à la fois selon le choix effectué.
Un code qui lit directement l’option timezone_string fonctionne parfaitement pour la moitié des sites, et retourne une chaîne vide pour l’autre moitié — ceux réglés avec un simple décalage numérique. wp_timezone_string() existe précisément pour uniformiser ces deux cas en une seule valeur exploitable.
Ce que fait la fonction
Si timezone_string est renseignée, wp_timezone_string() la retourne telle quelle, par exemple Europe/Paris. Si seul un décalage UTC a été choisi, elle le convertit en une chaîne de type +02:00, compatible avec les fonctions PHP de manipulation de date.
$fuseau = wp_timezone_string();
// 'Europe/Paris' ou '+01:00' selon le réglage du site
$zone = new DateTimeZone( $fuseau );
$maintenant = new DateTime( 'now', $zone );
echo $maintenant->format( 'd/m/Y H:i' );
Ce code fonctionne quel que soit le mode de réglage choisi par l’administrateur du site, sans condition supplémentaire à écrire dans le thème ou l’extension.
wp_timezone() : la version orientée objet
Depuis son introduction, WordPress propose également wp_timezone(), qui retourne directement un objet DateTimeZone déjà construit à partir du réglage du site, évitant même l’étape d’instanciation manuelle vue ci-dessus.
$maintenant = new DateTime( 'now', wp_timezone() );
Les deux fonctions coexistent : wp_timezone_string() reste utile lorsqu’une chaîne est nécessaire, par exemple pour un champ de configuration transmis à une bibliothèque tierce qui attend un identifiant de fuseau plutôt qu’un objet.
Pourquoi ne pas utiliser date_default_timezone_set
- Modifier le fuseau horaire global de PHP avec
date_default_timezone_set()affecte tout le processus, y compris du code tiers qui ne s’y attend pas. - WordPress conserve volontairement le fuseau serveur par défaut pour PHP, et gère son propre fuseau applicatif via les fonctions dédiées comme
current_time(),wp_timezone()etwp_timezone_string(). - Contourner cette convention en modifiant le fuseau global peut casser des extensions tierces qui comparent des horodatages bruts sans passer par l’API WordPress.
Cas particulier : aucun réglage explicite
Sur une installation fraîche, si aucun réglage n’a encore été modifié, gmt_offset vaut 0 par défaut. wp_timezone_string() retourne alors UTC, une valeur cohérente qui évite un décalage silencieux tant que l’administrateur n’a pas choisi son fuseau réel dans les réglages.
Avant d’écrire une fonction de formatage de date personnalisée, vérifiez toujours qu’elle s’appuie sur
wp_timezone()plutôt que sur un fuseau codé en dur. Un site multilingue ou multi-pays change parfois son réglage plusieurs fois avant sa mise en ligne définitive.
En résumé
wp_timezone_string() et son équivalent objet wp_timezone() évitent de traiter séparément les deux modes de réglage du fuseau horaire proposés par WordPress. S’appuyer systématiquement dessus, plutôt que de lire directement l’option timezone_string, garantit un affichage d’heure correct quel que soit le choix fait par l’administrateur du site.
