# current_time contre time() : obtenir une date dans le fuseau horaire du site

> Un horodatage enregistré avec time() peut afficher une heure décalée au client, selon le fuseau horaire configuré dans les réglages du site.

- Auteur : WordPress Développement
- Publié le : 2024-07-27
- Mis à jour le : 2024-07-27
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/current-time-contre-time-fuseau-horaire/

## L’essentiel

- time() renvoie toujours un horodatage en UTC, quel que soit le réglage du site
- current_time() applique le fuseau horaire configuré dans les réglages généraux
- Le second paramètre de current_time() choisit le format de retour, horodatage ou chaîne

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é

> L'essentiel à retenir : time() renvoie toujours un horodatage en UTC, quel que soit le réglage du site ; current_time() applique le fuseau horaire configuré dans les réglages généraux ; Le second paramètre de current_time() choisit le format de retour, horodatage ou chaîne

```
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 de `date()` 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()` par `current_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.