Un article programmé pour 14h s’affiche comme publié à 12h dans l’interface d’administration. Ce genre de décalage de deux heures, retrouvé sur de nombreux sites français, trahit presque toujours la même confusion : l’utilisation de time(), la fonction native de PHP, là où current_time(), sa contrepartie WordPress, aurait dû être utilisée.
time() renvoie systématiquement un horodatage Unix basé sur le fuseau horaire UTC, indépendamment de tout réglage propre au site WordPress. C’est un comportement cohérent et documenté côté PHP, mais qui ignore complètement le fuseau horaire configuré dans les réglages généraux du site, disponible sous Réglages > Général.
Ce que current_time() ajoute
current_time() prend en compte ce réglage de fuseau horaire pour renvoyer une valeur cohérente avec l’heure locale configurée par l’administrateur du site. Elle accepte un premier argument qui détermine le format de retour :
echo time();
// 1690449600 (horodatage UTC)
echo current_time( 'timestamp' );
// 1690456800 (horodatage ajusté selon le fuseau horaire du site, ex. UTC+2)
echo current_time( 'mysql' );
// 2023-07-27 14:00:00 (chaîne au format compatible MySQL, déjà ajustée)
Le format 'timestamp' renvoie un horodatage Unix, mais décalé pour refléter l’heure locale du site plutôt que l’UTC brut. Ce détail est important à comprendre : le résultat n’est techniquement plus un horodatage Unix « pur » au sens strict, puisqu’il intègre l’ajustement de fuseau horaire directement dans sa valeur numérique.
Un usage concret : horodater un enregistrement personnalisé
function enregistrer_signalement( $post_id, $motif ) {
add_post_meta( $post_id, 'signalements', array(
'motif' => sanitize_text_field( $motif ),
'date' => current_time( 'mysql' ),
) );
}
Utiliser current_time( 'mysql' ) plutôt que date( 'Y-m-d H:i:s' ) ou un horodatage brut garantit que la date enregistrée correspond bien à l’heure locale telle que configurée dans les réglages du site, cohérente avec ce que WordPress affiche par ailleurs dans son interface d’administration pour les autres contenus.
Le second paramètre, pour un résultat en UTC malgré tout
current_time() accepte un second paramètre optionnel, un booléen qui force le retour en UTC plutôt qu’en heure locale, si un contexte particulier l’exige malgré l’usage de cette fonction :
$horodatage_utc = current_time( 'timestamp', true );
// Équivalent, dans ce cas précis, à time().
Ce paramètre reste rarement utilisé en pratique, mais il permet de rester cohérent dans le choix de la fonction utilisée à travers tout un projet, plutôt que d’alterner entre time() et current_time() selon les endroits du code.
Comparer avec wp_date() pour le formatage
Une confusion fréquente consiste à utiliser current_time() pour formater une date destinée à l’affichage, un rôle qui revient plutôt à wp_date(). current_time() sert avant tout à obtenir une valeur temporelle exploitable — horodatage ou chaîne MySQL — au moment présent, tandis que wp_date() formate une date déjà connue, y compris une date passée ou future, selon les paramètres régionaux et le fuseau horaire du site :
$horodatage = get_post_time( 'U', true, $post_id );
echo wp_date( 'j F Y à H\hi', $horodatage );
// 27 juillet 2024 à 14h00
Les deux fonctions se complètent plutôt qu’elles ne se concurrencent : current_time() pour capturer un instant présent au bon fuseau horaire, wp_date() pour formater n’importe quelle date selon les réglages régionaux du site.
Repérer les décalages déjà en place
- Rechercher dans le code du projet les occurrences directes de
time()ou dedate()sans passage par les fonctions WordPress dédiées. - Vérifier le réglage de fuseau horaire du site sous Réglages > Général, souvent laissé sur sa valeur par défaut lors de l’installation initiale.
- Comparer une date enregistrée récemment avec l’heure réelle de l’action pour confirmer visuellement l’ampleur d’un éventuel décalage.
Sur tout code qui horodate une action utilisateur destinée à être affichée telle quelle, remplacer systématiquement
time()parcurrent_time( 'timestamp' )évite un décalage silencieux qui ne se remarque souvent qu’après plusieurs semaines de production.
En résumé
La différence entre les deux fonctions tient à une question simple : l’heure UTC brute intéresse-t-elle réellement le projet, ou faut-il refléter l’heure locale configurée par l’administrateur du site ? Dans l’immense majorité des cas d’horodatage visible par un utilisateur, c’est current_time() qui répond correctement à ce besoin, pas la fonction native de PHP.
