Accueil → Aide

Les horodatages du journal d'utilisation ne correspondent pas au moment de l'appel

La plupart des plateformes stockent les horodatages en UTC et les affichent soit en UTC, soit dans un fuseau horaire que vous avez défini une fois puis oublié. Comparer une horloge locale à un journal en UTC décale toutes les limites, d'où des totaux qui divergent aux bords de la journée.

Ce que vous voyez

A request you just made appears with yesterday's date
Daily totals do not match what you counted
Nothing in the log for the hour you were testing
Two tools report different totals for the same day

Pourquoi cela arrive

Les agrégats journaliers sont calculés sur une limite de jour. Si la vôtre est en UTC et que vous raisonnez en UTC+8, huit heures d'appels tombent dans ce que vous considérez comme la veille : toutes les données sont là, simplement regroupées autrement.

Les horodatages côté client proviennent de la machine qui a fait l'appel. Un serveur à l'horloge fausse ou dans un autre fuseau horaire produit un journal qui paraît incohérent avec lui-même.

Les filtres affichent souvent par défaut les dernières 24 heures plutôt que la journée en cours. Cette fenêtre glisse pendant que vous la regardez, si bien qu'un total semble changer tout seul.

Comment le corriger

Comparez en UTC des deux côtésConvertissez vos propres enregistrements en UTC avant le rapprochement. Faire l'inverse nécessite le fuseau d'affichage de la plateforme, facile à confondre.
Cherchez la requête précise plutôt que la journéeCherchez par id de requête, ou par modèle et heure approximative. Un enregistrement unique existe ou n'existe pas, sans limite à débattre.
Vérifiez l'horloge de l'appelantSi vos journaux diffèrent de ceux de la plateforme d'un décalage constant qui n'est pas un nombre entier d'heures, soupçonnez une dérive d'horloge sur la machine qui appelle.

APICLAN enregistre chaque appel en UTC avec son montant exact. Si une requête manque réellement au lieu d'être simplement décalée, cela signifie généralement qu'elle n'a jamais atteint la passerelle : une erreur de chemin ou de base URL, qui ne laisse aucun enregistrement.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI 401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.