# human_time_diff : afficher « il y a 3 jours » sans librairie de dates

> Faut-il vraiment charger une librairie JavaScript pour afficher une date relative dans un fil d'activité ? Le cœur de WordPress fait déjà le calcul côté PHP.

- Auteur : WordPress Développement
- Publié le : 2024-12-10
- Mis à jour le : 2024-12-10
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/human-time-diff-il-y-a-3-jours-sans-librairie/

## L’essentiel

- Retourne un texte relatif prêt à afficher
- Calcule automatiquement l'unité la plus lisible
- Fonction du cœur, sans dépendance JavaScript

Faut-il vraiment ajouter une dépendance JavaScript de plusieurs dizaines de kilo-octets pour afficher « il y a 3 jours » sous un commentaire ou une notification ? La réponse est non, et la fonction qui règle le problème est déjà présente dans chaque installation : `human_time_diff()`.

Elle est utilisée en coulisses par l'administration elle-même — la colonne « Date » de la liste des commentaires, par exemple, s'appuie dessus. Rien n'empêche de la réutiliser côté front pour un fil d'activité, une liste de tickets ou un flux de notifications internes.

## Ce que fait exactement la fonction

`human_time_diff( int $from, int $to = 0 )` prend deux horodatages Unix et retourne une chaîne du type « 3 jours », « 2 heures » ou « 1 minute », en choisissant automatiquement l'unité la plus pertinente. Si `$to` est omis, la fonction compare `$from` à l'heure courante du serveur au moment de l'appel.

Le résultat brut est une durée, sans le mot « il y a » : pour obtenir le texte complet affiché aux visiteurs, WordPress fournit une chaîne traduisible dédiée, généralement construite avec `sprintf()` autour de `human_time_diff()`, par exemple `sprintf( __( 'il y a %s' ), human_time_diff( $timestamp ) )`.

## Un fil d'activité pour une extension de support

> L'essentiel à retenir : Retourne un texte relatif prêt à afficher ; Calcule automatiquement l'unité la plus lisible ; Fonction du cœur, sans dépendance JavaScript

Prenons une extension de gestion de tickets pour un service client interne. Chaque ticket a une date de dernière réponse, et l'équipe veut voir en un coup d'œil lesquels traînent depuis longtemps :

```
function support_afficher_derniere_reponse( $ticket_id ) {
    $timestamp = get_post_meta( $ticket_id, '_derniere_reponse', true );

    if ( ! $timestamp ) {
        return esc_html__( 'Aucune réponse pour le moment', 'support-interne' );
    }

    return sprintf(
        /* translators: %s : durée écoulée, ex. "3 jours" */
        esc_html__( 'Dernière réponse il y a %s', 'support-interne' ),
        human_time_diff( (int) $timestamp )
    );
}
```

Le résultat s'affiche sans appel réseau supplémentaire, sans script tiers, et se met à jour naturellement à chaque nouveau chargement de page — ce qui suffit largement pour un tableau de bord interne rafraîchi régulièrement.

## Les limites à connaître

La fonction a deux comportements qu'il faut anticiper avant de l'utiliser en production :

- Elle ne gère qu'une seule unité à la fois : au-delà d'un certain seuil, elle bascule en semaines, puis en mois, puis en années, sans jamais combiner deux unités comme « 1 an et 2 mois ».
- Le résultat est arrondi, pas exact à la seconde près : deux appels séparés de quelques secondes peuvent produire le même texte, ce qui est très bien pour de la lisibilité mais à proscrire pour un calcul métier précis.
- Pour une date future par rapport à `$to`, la fonction retourne quand même une durée positive : le signe n'est pas géré, c'est à l'appelant de savoir si la date est passée ou à venir avant d'accoler « il y a » ou « dans ».

## Pourquoi éviter une dépendance JavaScript pour ce besoin

Des librairies comme celles qui gèrent le format relatif côté navigateur ont leur utilité quand l'affichage doit se rafraîchir tout seul, seconde par seconde, sans recharger la page — un chronomètre de compte à rebours, par exemple. Mais pour un fil d'activité classique, où chaque affichage correspond à un chargement de page ou à un rafraîchissement périodique, calculer la durée côté serveur avec `human_time_diff()` évite d'expédier du code supplémentaire au navigateur pour un résultat identique.

Cela simplifie aussi le rendu côté serveur pour un flux RSS, un export ou une notification par e-mail, où exécuter du JavaScript n'est de toute façon pas une option.

## Traduction et cohérence linguistique

Comme la chaîne produite dépend de la langue active du site, il vaut mieux systématiquement envelopper l'affichage final dans une fonction de traduction plutôt que de concaténer le résultat brut. Le tableau suivant résume les cas fréquents rencontrés en pratique :

| Situation | Fonction adaptée |
| --- | --- |
| Durée relative affichée à l'utilisateur | `human_time_diff()` |
| Date absolue formatée selon le fuseau du site | `wp_date()` |
| Objet date manipulable depuis un article | `get_post_datetime()` |

## Notre verdict

`human_time_diff()` couvre un besoin très courant — afficher une durée relative lisible — sans qu'il soit nécessaire d'aller chercher une dépendance externe. Elle est déjà chargée dans chaque installation, elle est traduite dans toutes les langues officielles de WordPress, et elle suffit largement pour un fil d'activité, une liste de tickets ou tout affichage qui ne réclame pas de mise à jour en temps réel seconde par seconde. Réserver une librairie JavaScript aux cas où le rafraîchissement doit se faire sans recharger la page permet de garder le reste du site plus léger.