get_gmt_from_date : convertir une date locale en UTC avant de l’enregistrer

echo get_gmt_from_date( current_time( 'mysql' ) ); — cette ligne renvoie l’heure actuelle convertie en temps universel, sans qu’il soit nécessaire de connaître le décalage horaire réglé dans l’administration du site. C’est exactement ce que cherche un développeur qui doit transmettre une date à un service tiers exigeant de l’UTC : une réservation, un webhook de synchronisation ou un export vers une API de facturation.

Le réflexe naturel consiste souvent à soustraire ou ajouter manuellement le nombre d’heures affiché dans Réglages > Général. Ce calcul fonctionne le jour où on l’écrit, puis casse discrètement au changement d’heure d’été, ou lorsque le site change de fuseau. get_gmt_from_date() évite ce piège en s’appuyant sur les réglages réels du site au moment de l’appel.

Le problème d’une date « locale » sans repère

Quand un article est publié, sa date est stockée dans post_date selon le fuseau du site, et dans post_date_gmt pour l’équivalent universel. Le cœur de WordPress fait déjà cette double écriture pour les contenus, mais un développeur qui manipule ses propres dates — un rendez-vous, une date d’expiration d’offre, un horodatage métier — n’a pas ce filet de sécurité automatiquement. Il doit produire lui-même la version UTC quand un système externe en a besoin.

Sans fonction dédiée, la tentation est de faire quelque chose comme récupérer l’option gmt_offset et l’appliquer à coups de strtotime() et d’arithmétique sur les secondes. Cela ignore les transitions d’heure d’été gérées par les fuseaux nommés (« Europe/Paris » plutôt qu’un simple décalage numérique), et le résultat peut être décalé d’une heure une bonne partie de l’année.

La fonction native et sa signature

get_gmt_from_date( string $string, string $format = 'Y-m-d H:i:s' ) prend une date exprimée dans le fuseau local du site et retourne la chaîne équivalente en UTC, formatée selon le second paramètre. À l’inverse, get_date_from_gmt() fait le chemin retour, d’une date UTC vers l’heure locale — mais ce n’est pas le sujet ici, cet article se concentre sur la conversion vers l’UTC avant enregistrement ou envoi.

Le format d’entrée attendu est celui d’une date MySQL classique, Y-m-d H:i:s. C’est exactement ce que renvoie current_time( 'mysql' ), ce qui rend le duo pratique pour obtenir « maintenant, en UTC » sans passer par un objet DateTime intermédiaire.

Un exemple concret : synchroniser une réservation

Imaginons une extension qui gère des créneaux de réservation pour un atelier de réparation de vélos et qui doit notifier un service de planification externe à chaque prise de rendez-vous. Ce service attend une date ISO 8601 en UTC. Voici comment produire cette valeur proprement :

function atelier_notifier_creneau( $post_id, $creneau_local ) {
    // $creneau_local est au format MySQL, fuseau du site : '2024-08-27 16:30:00'
    $creneau_gmt = get_gmt_from_date( $creneau_local, 'Y-m-d\TH:i:s\Z' );

    $reponse = wp_remote_post( 'https://planning.exemple.test/api/creneaux', array(
        'headers' => array( 'Content-Type' => 'application/json' ),
        'body'    => wp_json_encode( array(
            'post_id'   => $post_id,
            'debut_utc' => $creneau_gmt,
        ) ),
    ) );

    if ( is_wp_error( $reponse ) ) {
        error_log( 'Notification planning échouée : ' . $reponse->get_error_message() );
    }
}

Le second paramètre de get_gmt_from_date() accepte n’importe quel format compatible date(), ce qui permet de produire directement une chaîne ISO 8601 terminée par un Z, sans étape de reformatage supplémentaire.

Le piège du fuseau du site, pas celui du serveur

Une confusion fréquente : get_gmt_from_date() ne se base pas sur le fuseau du serveur d’hébergement, mais sur celui réglé dans Réglages > Général du site WordPress lui-même. Deux installations sur le même serveur, avec des fuseaux différents, produiront donc des conversions différentes pour une même heure locale saisie — ce qui est précisément le comportement voulu, mais qu’il faut garder en tête au moment de déboguer un écart inattendu.

Ce point compte particulièrement lors d’une migration de site où le fuseau a été modifié entre l’ancien et le nouvel environnement : rejouer d’anciennes dates locales avec cette fonction donnera un résultat UTC différent de celui produit à l’époque, puisque le calcul dépend du réglage courant, pas de celui en vigueur au moment de la saisie initiale.

Quand préférer un objet DateTime

• Pour une conversion ponctuelle vers une chaîne, get_gmt_from_date() reste la solution la plus directe et la plus lisible.
• Pour des calculs plus riches (ajouter des jours, comparer deux dates, gérer des intervalles), un objet DateTimeImmutable construit avec le bon fuseau via DateTimeZone devient plus adapté.
• Pour repartir d’un article existant, get_post_datetime() fournit directement un objet date sans reconstruire quoi que ce soit à partir de chaînes.

Sur un projet de prise de rendez-vous, mieux vaut convertir vers l’UTC au moment de l’envoi plutôt que de stocker la date déjà convertie : cela évite de devoir tout recalculer si le fuseau du site change un jour.

En résumé

get_gmt_from_date() résout un problème précis et récurrent : obtenir l’équivalent UTC d’une date locale sans reconstruire un calcul de décalage horaire fragile. Elle existe dans le cœur de WordPress depuis très longtemps, s’appuie sur le fuseau réellement configuré pour le site, et accepte n’importe quel format de sortie compatible avec date(). Pour tout échange avec un service externe qui exige de l’UTC — API de réservation, webhook, export de données — c’est la brique la plus fiable, et elle évite d’introduire une dépendance supplémentaire pour un besoin que le cœur couvre déjà.