Bevorzugtes Format von Dateinamen, die einen Zeitstempel enthalten

Wie wir alle wissen, kann "Unix" alles in einer Datei haben, außer '/' und '\ 0', aber Sysadmins tendieren dazu, eine viel geringere Präferenz zu haben, hauptsächlich, weil sie Leerzeichen als Eingabe nicht mögen ... und eine Menge Dinge haben eine besondere Bedeutung unter anderem für ':' und '@'.

Kürzlich hatte ich noch einen anderen Fall gesehen, in dem ein Zeitstempel in einem Dateinamen verwendet wurde, und nachdem ich ein bisschen mit verschiedenen Formaten gespielt hatte, um es "besser" zu machen, dachte ich mir, ich würde versuchen, eine "Best Practice" zu finden, ohne eine zu sehen, die ich dachte Ich würde hier nur fragen und sehen, was die Leute dachten.

Mögliche "gemeinsame" Lösungen (p = Präfix und s = Suffix):

1. syslog / logrotate / DNS ähnliches Format:

   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
   

   Profis:

   • Es ist "gewöhnlich", also ist "gut genug" vielleicht besser als "am besten".
   • Keine komischen Charaktere.
   • Leicht zu unterscheidender "Datum / Uhrzeit-Fleck" von allem anderen.

   Nachteile:

   • Die Nur-Datum-Version ist nicht leicht zu lesen, und wenn ich die Zeit mitzähle, bluten meine Augen, und auch die Sekunden sind nur "lol".
   • Angenommen, TZ.

2. ISO-8601-Format

   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
   

   Profis:

   • Kein Platz.
   • Berücksichtigt TZ.
   • Ist von Menschen "nicht schlecht" zu lesen (Datum ist nur v. Gut).
   • Kann durch $ generiert werden (Datum --iso = {Stunden, Minuten, Sekunden})

   Nachteile:

   • scp / tar / etc. mag diese ':' Zeichen nicht.
   • Dauert ein bisschen, damit "normale" Leute WTF sehen, für die "T" ist, und was die Sache am Ende ist :).
   • Viele '-' Zeichen.

3. RFC-3339-Format

   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
   

   Profis:

   • Berücksichtigt TZ.
   • Kann leicht von "allen Menschen" gelesen werden.
   • Kann Datum / Uhrzeit von Präfix / Suffix unterscheiden.
   • Einige der oben genannten Werte können mit $ (Datum --iso = {Stunden, Sekunden}) generiert werden.

   Nachteile:

   • Hat Leerzeichen in den Zeitversionen (was bedeutet, dass der gesamte Code es hassen wird).
   • scp / tar / etc. mag diese ':' Zeichen nicht.

4. Ich liebe Bindestriche:

   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
   

   Profis:

   • im grunde ein etwas netteres syslog / etc. Variante.

   Nachteile:

   • Viele '-' Zeichen.
   • Angenommen, TZ.

5. Ich liebe Bindestriche mit Erweiterungen:

   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
   

   Profis:

   • Im Grunde genommen eine etwas schönere Variante "Ich liebe Bindestriche".
   • Keine komischen Charaktere.
   • Kann Datum / Uhrzeit von Präfix / Suffix unterscheiden.

   Nachteile:

   • '.' Verwenden hier ist etwas untraditionell.
   • Angenommen, TZ.

... daher möchte jeder eine Präferenz und einen Grund oder mehr als einen angeben (z. B. ist TZ egal, wenn 95% der Maschinen lokal bleiben, aber es ist sehr wichtig, wenn dies nicht der Fall ist).

Oder natürlich etwas, das nicht in der obigen Liste enthalten ist.

1. Das ISO 8601-Format sollte so weit wie möglich eingehalten werden, da es einer Norm am nächsten kommt.
2. Das 'T' ist nicht genug Stolperstein, um es wirklich loszuwerden.
3. Die ':' s sind potenzielle Killer, daher sollten diese vermieden werden.
4. Aus den in den Antworten anderer genannten Gründen sollte UTC (oder 'Z'-Zeit) verwendet werden.
5. ISO 8601 enthält ein Format unter Verwendung von UTC ('Z'-Zeit), das verwendet werden sollte.
6. ISO 8601 enthält ein Format, das nicht das Zeichen ':' verwendet, das verwendet werden sollte.

Also ... probieren Sie 'beste' Datums- / Uhrzeitformate:

1. 20120317T1748Z

   • 100% gemäß ISO 8601
   • Nur alphanumerische Zeichen (sehr sysadmin-freundlich)
   • nicht am schnellsten zu lesen, aber für den Laien durchaus lesbar

2. 2012-03-17T1748Z

   • Datumsangabe entspricht ISO 8601
   • Zeitanteil entspricht ISO 8601
   • Der Übergang zwischen Datum und Uhrzeit entspricht ISO 8601
   • Mischt das ISO 8601-Format "Erweitert" (Datum mit Bindestrichen, Uhrzeit mit Doppelpunkten) mit dem ISO 8601-Format "Basis" (Datum ohne Bindestriche, Uhrzeit ohne Doppelpunkte), was wahrscheinlich nicht ganz richtig ist
   • fügt '-' Zeichen hinzu (vs 1.)
   • für den Laien etwas leichter zu lesen (vs. 1.)

3. 2012-03-17--1748Z

   • Datumsangabe entspricht ISO 8601
   • Zeitanteil entspricht ISO 8601
   • Der Übergang zwischen Datum und Uhrzeit entspricht nicht ISO 8601
   • Mischt das erweiterte ISO 8601-Format mit dem Basisformat von ISO 8601
   • für den Laien etwas leichter zu lesen (vs. 1. und 2.)
   • keine neuen Charaktere (vs 2.)

Ich bin teilweise zu 1., da es voll IAW der Standard ist, aber die anderen sind nah.

Hinweis: Fügen Sie bei Bedarf natürlich Sekunden hinzu. ... und ja, mit oder ohne Sekunden (oder sogar Minuten) ist alles IAW ISO 8601. :)

Ich würde keine Zeitzone angeben, sondern nur die Weltzeit verwenden. Im Zweifelsfall können Sie ein -UTC-Suffix hinzufügen. Wenn Sie eine Zeitzone angeben, kann sich jemand darauf verlassen. Und es würde seltsame Randfälle geben, in denen DST-Änderungen oder DST-Verschiebungen bei einigen Verarbeitungen verheerende Folgen haben oder die Verarbeitungen auf einigen Systemen unterschiedlich sind, weil ihre DST-Konfiguration nicht aktuell ist. UTC ist überall immer gleich.

Ich denke, dass Bindestriche den Dateinamen lesbarer machen, in dem Sinne, dass es einfacher ist, die Datumszeit der Dateidaten zu erkennen. Wenn Sie eine Genauigkeit von weniger als einer Sekunde angeben möchten, ist dies normalerweise .nnnnn.

Ich persönlich mag das T. nicht. Die Verwendung eines Doppelpunkts in einem Dateinamen kann die Interoperabilität mit anderen Dateisystemen beeinträchtigen.

1. Ich würde auch keine Zeitzonen angeben. Ihre Skripte / Tools, die die Protokolle verarbeiten, sollten darüber Bescheid wissen. Auch in Bezug auf Sommer- / Winterzeitänderungen - Ich würde empfehlen, Ihren Server immer auf UTC zu fixieren. Ein plötzlicher Unterschied zwischen der Zeitzone des Basisservers und einer (unveränderten) Zeitzone einer darauf laufenden Datenbank kann zu Kopfschmerzen führen ;-).

2. In Bezug auf die Benennung von Protokolldateien - Ich weiß, viele mögen es nicht, aber ich halte es gerne einfach:

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

Profis:

• gemeinsamer Nenner
• Sehr einfach in weiteren Skripten zu verwenden

Nachteile:

• nicht menschlich lesbar

Auf Maschinen, auf denen Kollegen (aus welchen Gründen auch immer) Protokolle manuell prüfen müssen, habe ich mich für diese Variante entschieden und wechselte täglich:

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

Freundliche Grüße