$date = new DateTime( $post->post_date ); — cette ligne fonctionne, mais elle reconstruit à la main un objet date à partir d’une chaîne déjà stockée sur l’article, sans tenir compte du fuseau horaire de façon explicite, et sans profiter de l’immutabilité qu’offre DateTimeImmutable. Depuis WordPress 5.3, get_post_datetime() évite cette reconstruction manuelle.
Cette fonction répond à un besoin fréquent dans le développement d’extensions et de thèmes : obtenir un objet date manipulable — pour comparer, formater, ajouter un intervalle — directement à partir d’un article, sans passer par une étape intermédiaire de parsing de chaîne.
La signature et ses deux paramètres de contexte
get_post_datetime( int|WP_Post $post = null, string $field = 'date', string $source = 'local' ) retourne un objet DateTimeImmutable, ou false en cas d’échec. Le paramètre $field accepte 'date' pour la date de publication ou 'modified' pour la date de dernière modification. Le paramètre $source accepte 'local' pour le fuseau du site, ou 'gmt' pour l’équivalent UTC déjà stocké en base.
Ce dernier paramètre évite une confusion fréquente avec l’approche manuelle : reconstruire un objet date à partir de post_date mélange souvent, sans le vouloir, une chaîne locale avec un fuseau UTC appliqué par défaut par DateTime, ce qui décale silencieusement le résultat. get_post_datetime() force à choisir explicitement la source, ce qui réduit ce risque.
Afficher une date de modification relative
Un site d’actualités qui veut afficher, sous chaque article, depuis combien de temps il a été mis à jour pour la dernière fois, peut combiner cette fonction avec human_time_diff() :
function actualites_afficher_derniere_maj( $post_id ) {
$date_maj = get_post_datetime( $post_id, 'modified' );
if ( false === $date_maj ) {
return '';
}
return sprintf(
/* translators: %s : durée écoulée, ex. "2 heures" */
esc_html__( 'Mis à jour il y a %s', 'actualites-locales' ),
human_time_diff( $date_maj->getTimestamp() )
);
}
Aucune conversion de chaîne, aucun appel à strtotime() : l’objet DateTimeImmutable retourné expose directement getTimestamp(), ainsi que toutes les méthodes classiques de manipulation de date offertes par l’extension DateTime de PHP.
Comparer deux dates d’articles
L’immutabilité de l’objet retourné simplifie les comparaisons, puisqu’aucune méthode appelée dessus ne modifie l’objet d’origine :
$date_a = get_post_datetime( $article_a_id );
$date_b = get_post_datetime( $article_b_id );
if ( $date_a && $date_b && $date_a < $date_b ) {
// $article_a_id a été publié avant $article_b_id.
}
Ce que cette fonction ne fait pas
- Elle ne formate rien pour l’affichage : pour un rendu localisé selon la langue du site,
wp_date()reste l’outil adapté, appliqué séparément sur le timestamp obtenu. - Elle ne donne pas non plus l’heure actuelle du site : ce rôle revient à
current_time()ou à un objet construit avec le fuseau retourné parwp_timezone(). - Elle retourne
false, pas une exception, en cas d’article introuvable ou de date invalide : ce retour doit être vérifié avant d’appeler une méthode dessus, sous peine d’erreur fatale sur un appel de méthode sur une valeur booléenne.
Toujours vérifier que get_post_datetime() n’a pas retourné false avant d’appeler une méthode sur le résultat : un article supprimé entre deux requêtes suffit à provoquer ce cas.
Un repère utile : la fonction miroir pour écrire une date
Cet article s’est concentré sur la lecture d’une date déjà enregistrée. Pour l’opération inverse — enregistrer une date de publication précise sur un article, par exemple lors d’une importation de contenu — la clé post_date attendue par wp_update_post() reste au format chaîne classique, et non un objet DateTimeImmutable : les deux fonctions ne sont donc pas de simples miroirs l’une de l’autre, ce qui mérite d’être gardé en tête pour éviter une conversion inutile ou, à l’inverse, un format oublié.
En résumé
get_post_datetime() évite une reconstruction manuelle d’objet date à partir des champs bruts d’un article, avec un risque de confusion de fuseau en moins grâce à son paramètre de source explicite. Pour tout traitement qui va au-delà d’un simple affichage — comparaison, calcul d’intervalle, tri par date — cette fonction reste le point de départ le plus direct, avant tout affichage géré séparément par wp_date() ou une fonction de durée relative.
