Donc parce que dans ton cas particulier ça ne te sert pas, tu pense que ça ne sert à rien ?
Non, je pense qu'il faut rester raisonnable. Le fuseau horaire n'est important que dans certains cas particuliers, comme tu viens de l'expliquer, pas dans *tous* les cas. Et pourquoi pas rendre le format de date configurable, tiens, par exemple?
Dans le cas où les journaux sont recyclés sur base journalière, à l’extrême, seul le jour et l'heure ont de l'importance. Par contre, dans le cas où la séquence des événements doit être mise en parallèle avec d'autres machines, de localisation et fuseau horaire différents, rien n'empêche d'utiliser un format plus complet, incluant date, heure et fuseau horaire; on importe le tout dans une base de données avec la date correctement formatée au départ. Si mes souvenirs sont exacts, PostgreSQL, par exemple, accepte des dates avec information de fuseau horaire et avec des données horaires jusqu'à la milliseconde.
Dans toutes mes argumentations, j'ai tenté de montrer que tous les reproches que l'ont fait à la mise en œuvre de données au format texte ont une solution qui ne passe pas nécessairement par le binaire.
> C'est quoi l'info la plus importante? Le fuseau horaire, c'est ça?
Donc on ne garde que la plus importante ? On ne met que le message du développeur alors, parce que toutes les méta données (le pid, le port, le niveau de gravité, etc) ne servent à rien si tu ne sais pas ce qui s'est passé.
Il y a une différence entre retirer ce qui n'est pas pertinent (pour le cas d'utilisation considéré) et ne garder que l'information la plus pertinente. Je parlais du premier cas.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . En réponse à la dépêche Documentation du format du Journal. Évalué à 0.
Non, je pense qu'il faut rester raisonnable. Le fuseau horaire n'est important que dans certains cas particuliers, comme tu viens de l'expliquer, pas dans *tous* les cas. Et pourquoi pas rendre le format de date configurable, tiens, par exemple?
Dans le cas où les journaux sont recyclés sur base journalière, à l’extrême, seul le jour et l'heure ont de l'importance. Par contre, dans le cas où la séquence des événements doit être mise en parallèle avec d'autres machines, de localisation et fuseau horaire différents, rien n'empêche d'utiliser un format plus complet, incluant date, heure et fuseau horaire; on importe le tout dans une base de données avec la date correctement formatée au départ. Si mes souvenirs sont exacts, PostgreSQL, par exemple, accepte des dates avec information de fuseau horaire et avec des données horaires jusqu'à la milliseconde.
Dans toutes mes argumentations, j'ai tenté de montrer que tous les reproches que l'ont fait à la mise en œuvre de données au format texte ont une solution qui ne passe pas nécessairement par le binaire.
Il y a une différence entre retirer ce qui n'est pas pertinent (pour le cas d'utilisation considéré) et ne garder que l'information la plus pertinente. Je parlais du premier cas.