Analyser les horodatages de journaux
Le 25/Jul/2026:14:30:00 +0200 d'Apache, le Jul 25 14:30:00 de syslog et le 2026-07-25T14:30:00.123Z ressortent chacun en une heure ISO 8601 UTC, avec les millisecondes depuis l'époque Unix et le format reconnu. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Texte
- 2026-07-25T14:30:00.123Z INFO worker started
- Iso
- 2026-07-25T14:30:00.123Z
- Époque (ms)
- 1 784 989 800 123
- Format de sortie
- iso8601
Les fichiers journaux ne s'accordent pas sur la façon d'écrire un horodatage. Votre application émet de l'ISO 8601, l'hôte écrit en syslog, et le serveur web horodate tout au format Apache common log : fusionner trois sources impose donc de réécrire le même code d'analyse encore une fois. Un seul appel remplace un empilement d'expressions régulières par format et de calculs de fuseaux horaires.
Trois formats, une réponse normalisée
Chaque source de journaux a choisi sa propre convention il y a des décennies et n'en a jamais dévié. Les horodatages ISO 8601 comme 2026-07-25T14:30:00.123Z sont sans ambiguïté, mais ce n'est qu'un des formats que vous rencontrerez sur le terrain. Les lignes syslog conformes à la RFC 3164 s'ouvrent sur un horodatage comme Jul 25 14:30:00 — sans année, sans fuseau horaire, avec un double espace lorsque le jour ne comporte qu'un chiffre.
Les journaux d'accès d'Apache et de nginx au format common log adoptent une forme entièrement différente : 25/Jul/2026:14:30:00 +0200, avec des barres obliques, des deux-points et un fuseau numérique. L'analyseur d'horodatages de journaux accepte l'horodatage placé en tête d'une ligne dans l'un des trois formats et répond par une unique chaîne ISO 8601 UTC normalisée, les millisecondes epoch et le nom du format reconnu. Vous cessez de traiter chaque source différemment : quoi qu'il arrive, un seul champ vous indique quand l'événement s'est produit.
Toute ligne qui ne commence pas par un horodatage connu est rejetée avec une erreur explicite plutôt qu'avec une date devinée, de sorte qu'une ligne malformée échoue bruyamment en amont au lieu de corrompre silencieusement vos analyses en aval.
Ce que la normalisation signifie vraiment
C'est dans la normalisation que se cachent les bogues subtils, aussi les règles sont-elles énoncées clairement. Une entrée ISO 8601 dotée d'un décalage explicite, par exemple 2026-07-25T16:30:00+02:00, est convertie en UTC et renvoyée sous la forme 2026-07-25T14:30:00.000Z — le même instant, une seule écriture canonique. Un horodatage ISO dépourvu de fuseau est présumé être en UTC, ce qui constitue le comportement par défaut le moins surprenant pour des journaux de serveurs.
Le fuseau numérique obligatoire d'Apache est respecté à la lettre. Les fractions de seconde sont conservées à la milliseconde près. La validation calendaire est stricte : un 30 février, une 25e heure ou une 61e seconde sont des erreurs, et non des bascules silencieuses au jour suivant, car un pipeline de journaux qui accepte des dates impossibles finira tôt ou tard par vous induire en erreur pendant un incident.
Conçu pour les pipelines, déterministe par nature
L'analyseur est une fonction pure : des expressions régulières pour reconnaître le format, puis une arithmétique calendaire entière pour convertir entre dates civiles et epoch. Il ne consulte jamais l'horloge système, n'appelle jamais le réseau et ne dépend jamais du fuseau horaire de la machine sur laquelle il s'exécute, ce qui signifie que la même entrée produit la même sortie dans vos tests aujourd'hui et en production dans un an.
Ce déterminisme compte lorsque vous rejouez des journaux archivés dans un nouveau pipeline et attendez que la chronologie reconstruite corresponde à l'originale octet par octet. Les usages typiques sont la normalisation d'archives aux formats mixtes avant leur chargement dans un moteur de recherche, l'alignement d'événements issus de journaux d'application, système et serveur web sur une même chronologie UTC lors d'une analyse d'incident, et la vérification qu'un agent d'expédition horodate bien ses lignes dans le format attendu par votre collecteur.
Cas d’usage
Fusionner des journaux de sources différentes
Normalisez les horodatages ISO, syslog et Apache sur une même chronologie UTC avant de charger des archives mixtes dans votre système de journaux.
Reconstituer la chronologie d'un incident
Alignez chronologiquement les événements applicatifs, système et serveur web lorsque chaque couche a horodaté ses lignes différemment.
Valider le format d'un agent d'expédition
Vérifiez que les lignes émises par vos agents commencent bien par le format d'horodatage attendu par votre collecteur, en rejetant tôt les lignes malformées.
Questions fréquentes
Combien cela coûte-t-il ?
Le même analyseur fonctionne également gratuitement dans votre navigateur sur cette page.
Quels formats d'horodatage sont pris en charge ?
ISO 8601 (avec ou sans fractions de seconde et décalage de fuseau horaire), syslog selon la RFC 3164 comme 'Jul 25 14:30:00', et le format Apache common log comme '25/Jul/2026:14:30:00 +0200'.
Et si un horodatage n'a pas de fuseau horaire ?
Il est présumé être en UTC. Les horodatages dotés d'un décalage explicite sont convertis en UTC, de sorte que chaque réponse revient sous la même forme normalisée.
Et si la ligne ne commence pas par un horodatage connu ?
Les dates impossibles comme le 30 février ou l'heure 25 sont rejetées de la même manière.
Mes données de journaux sont-elles conservées ?
Non. La ligne est analysée en mémoire puis supprimée ; seul l'horodatage normalisé est renvoyé.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/dev/timestamp-log-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"2026-07-25T14:30:00.123Z INFO worker started"}'const res = await fetch("https://api.kit.forhosting.com/dev/timestamp-log-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "2026-07-25T14:30:00.123Z INFO worker started"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/timestamp-log-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "2026-07-25T14:30:00.123Z INFO worker started"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/timestamp-log-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"2026-07-25T14:30:00.123Z INFO worker started"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"2026-07-25T14:30:00.123Z INFO worker started"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/timestamp-log-parse", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"text": "2026-07-25T14:30:00.123Z INFO worker started"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.timestamp_log_parse",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
max_chars | 10000 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Cette API prend une ligne de journal, lit l'horodatage situé à son début dans l'un des trois formats, et le renvoie normalisé en ISO 8601 UTC, accompagné des millisecondes epoch et du format reconnu.
Ce que la normalisation signifie vraiment
L'année absente de syslog est le seul cas où une hypothèse est inévitable : la RFC 3164 ne la transporte tout simplement pas, donc l'analyseur la complète à partir du paramètre default_year (2000 sauf si vous en transmettez une autre) et marque le résultat avec year_assumed: true afin que la sortie elle-même reconnaisse cette hypothèse.
Conçu pour les pipelines, déterministe par nature
Le même code s'exécute gratuitement dans votre navigateur sur cette page — collez une ligne, voyez le résultat — et coûte $0.002 par requête lorsque vous l'automatisez via l'API, sans qu'aucun fichier ni aucune ligne ne soit conservé après le renvoi de la réponse.
Questions techniques
Que se passe-t-il avec les lignes syslog sans année ?
L'année est complétée à partir du paramètre default_year (2000 sauf si vous transmettez la vôtre) et le résultat est marqué avec year_assumed: true afin que l'hypothèse soit visible dans la sortie.