Format préféré des noms de fichiers qui incluent un horodatage

Comme nous savons tous que "unix" peut avoir n'importe quoi dans un fichier à l'exception de '/' et '\ 0', les administrateurs système ont cependant tendance à avoir une préférence beaucoup plus petite, principalement en raison de rien qui n'aime pas les espaces en entrée ... et un tas de choses ayant une signification spéciale pour «:» et «@» entre autres.

Récemment, j'avais vu un autre cas où un horodatage était utilisé dans un nom de fichier, et après avoir joué un peu avec différents formats pour le rendre "meilleur", j'ai pensé que j'essaierais de trouver une "meilleure pratique", sans en voir un que j'ai figuré Je voudrais simplement demander ici et voir ce que les gens pensaient.

Solutions "courantes" possibles (p = préfixe et s = suffixe):

1. Format de type syslog / logrotate / DNS:

   p-%Y%m%d-suffix = prefix-20110719-s
   p-%Y%m%d%H%M-suffix = prefix-201107191732-s
   p-%Y%m%d%H%M%S-suffix = prefix-20110719173216-s
   

   avantages:

   • C'est "commun", donc "assez bon" pourrait être meilleur que "meilleur".
   • Pas de personnages étranges.
   • Il est facile de distinguer le "blob date / heure" de tout le reste.

   les inconvénients:

   • La version date seulement n'est pas facile à lire, et y compris l'heure me fait saigner les yeux et les secondes, c'est juste "lol".
   • Suppose TZ.

2. Format ISO-8601

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%dT%H:%M%z-s = p-2011-07-19T17:32-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T17:32:16-0400-s
   p-%Y-%m-%dT%H:%M:%S%z-s = p-2011-07-19T23:32:16+0200-s
   

   avantages:

   • Sans espaces.
   • Tient compte de TZ.
   • Est "pas mal" à lire par les humains (seule la date est très bonne).
   • Peut être généré par $ (date --iso = {heures, minutes, secondes})

   les inconvénients:

   • scp / tar / etc. n'aimera pas ces caractères ':'.
   • Il faut un peu pour que les gens «normaux» voient WTF à quoi «T» est destiné, et à quoi ça sert à la fin :).
   • Beaucoup de caractères «-».

3. format rfc-3339

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d %H:%M%:z-s = p-2011-07-19 17:32-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 17:32:16-04:00-s
   p-%Y-%m-%d %H:%M:%S%:z-s = p-2011-07-19 23:32:16+02:00-s
   

   avantages:

   • Tient compte de TZ.
   • Peut facilement être lu par "tous les humains".
   • Peut distinguer la date / l'heure du préfixe / suffixe.
   • Certains des éléments ci-dessus peuvent être générés avec $ (date --iso = {heures, secondes})

   les inconvénients:

   • A des espaces dans les versions temporelles (ce qui signifie que tout le code le déteste).
   • scp / tar / etc. n'aimera pas ces caractères ':'.

4. J'adore les tirets:

   p-%Y-%m-%d-s = p-2011-07-19-s
   p-%Y-%m-%d-%H-%M-s = p-2011-07-19-17-32-s
   p-%Y-%m-%d-%H-%M-%S-s = p-2011-07-19-23-32-16-s
   

   avantages:

   • essentiellement un syslog légèrement plus agréable / etc. une variante.

   les inconvénients:

   • Beaucoup de caractères «-».
   • Suppose TZ.

5. J'adore les tirets, avec des extensions:

   p.%Y-%m-%d.s = p.2011-07-19.s
   p.%Y-%m-%d.%H-%M.s = p.2011-07-19.17-32.s
   p.%Y-%m-%d.%H-%M-%S.s = p.2011-07-19.23-32-16.s
   

   avantages:

   • en gros une variante un peu plus agréable "j'aime les traits d'union".
   • Pas de personnages étranges.
   • Peut distinguer la date / l'heure du préfixe / suffixe.

   les inconvénients:

   • En utilisant '.' ici est quelque peu non traditionnel.
   • Suppose TZ.

... donc tout le monde veut donner une préférence et une raison, ou plus d'une (par exemple, ne vous souciez pas de TZ si c'est + 95% pour rester local, mais faites attention si ce n'est pas le cas).

Ou, évidemment, quelque chose qui ne figure pas dans la liste ci-dessus.

1. Le format ISO 8601 doit être respecté autant que possible, car c'est la chose la plus proche d'une norme.
2. Le «T» n'est pas assez une pierre d'achoppement pour vraiment justifier de s'en débarrasser.
3. Les «:» sont potentiellement des tueurs, donc ceux-ci doivent être évités.
4. Pour les raisons mentionnées dans les réponses des autres, le temps UTC (ou «Z») doit être utilisé.
5. ISO 8601 comprend un format utilisant UTC (heure «Z»), qui doit être utilisé.
6. ISO 8601 inclut un format qui n'utilise pas le caractère «:», qui devrait être utilisé.

Alors ... exemples de «meilleurs» formats date-heure:

1. 20120317T1748Z

   • 100% conforme à ISO 8601
   • caractères alphanumériques uniquement (très convivial pour les administrateurs système)
   • pas le plus rapide à lire, mais certainement lisible par le profane

2. 2012-03-17T1748Z

   • la date est conforme à la norme ISO 8601
   • la portion de temps est conforme à la norme ISO 8601
   • la transition entre la date et l'heure est conforme à la norme ISO 8601
   • mélange le format «étendu» ISO 8601 (date avec tirets, heure avec deux points) avec le format «basique» ISO 8601 (date sans tirets, heure sans deux-points), ce qui n'est probablement pas tout à fait exact
   • ajoute le caractère '-' (vs 1.)
   • un peu plus facile à lire pour le profane (vs 1.)

3. 2012-03-17--1748Z

   • la date est conforme à la norme ISO 8601
   • la portion de temps est conforme à la norme ISO 8601
   • la transition entre la date et l'heure n'est pas conforme à la norme ISO 8601
   • mélange le format «étendu» ISO 8601 avec le format «de base» ISO 8601
   • un peu plus facile à lire pour le profane (vs 1. et 2.)
   • pas de nouveaux personnages (vs 2.)

Je suis partiel à 1. car il est entièrement conforme à la norme, mais les autres sont proches.

Remarque :: Ajoutez des secondes si nécessaire, bien sûr. ... et oui, avec ou sans secondes (ou même minutes), tout est conforme à ISO 8601. :)

Je n'inclurais pas de fuseau horaire, j'utiliserais uniquement l'heure universelle. En cas de confusion, vous pouvez ajouter un suffixe -UTC. Si vous spécifiez un fuseau horaire, quelqu'un peut en dépendre. Et il y aurait des cas étranges où les changements d'heure d'été ou les changements d'heure d'été font des ravages sur certains traitements, ou le traitement est différent sur certains systèmes car leur configuration d'heure d'été n'est pas à jour. L'UTC est toujours le même partout.

Je pense que les tirets rendent le nom du fichier plus lisible, dans le sens où il est plus facile de discerner la date et l'heure des données du fichier. Si vous souhaitez inclure une précision inférieure à une seconde, il s'agit généralement de .nnnnn.

Personnellement, je n'aime pas le T. L'utilisation de deux points dans un nom de fichier peut affecter l'interopérabilité avec d'autres systèmes de fichiers.

1. Moi aussi, je n'inclurais pas les fuseaux horaires. Vos scripts / outils qui traitent les journaux devraient le savoir. Aussi en ce qui concerne les changements d'heure d'été / d'hiver - je recommanderais de garder votre serveur toujours fixe à UTC tout le temps. Une différence soudaine entre le fuseau horaire du serveur de base et un fuseau horaire (inchangé) d'une base de données s'exécutant dessus peut entraîner des maux de tête ;-).

2. En ce qui concerne la dénomination des fichiers journaux - je sais, beaucoup ne l'aiment pas, mais j'aime rester simple:

p-%s-type.log = p-1311116459-type.log

avantages:

• dénominateur commun
• très facile à utiliser dans d'autres scripts

les inconvénients:

• non lisible par l'homme

Sur les machines où des collègues (pour une raison quelconque) doivent vérifier les journaux manuellement, j'ai opté pour cette variante, en effectuant une rotation quotidienne:

p-%Y-%m-%d-type.log = p-2011-07-20-type.log

Meilleures salutations