Preferowany format nazw plików, które zawierają znacznik czasu


16

Jak wszyscy wiemy, „unix” może zawierać w pliku wszystko oprócz „/” i „\ 0”, sysadmini mają jednak znacznie mniejsze preferencje, głównie z powodu braku lubienia spacji jako danych wejściowych ... i wielu rzeczy mających specjalne znaczenie między innymi „:” i „@”.

Ostatnio widziałem inny przypadek, w którym w nazwie pliku użyto znacznika czasu, a po graniu w różnych formatach, aby było „lepiej”, pomyślałem, że spróbuję znaleźć „najlepszą praktykę”, a nie taką, którą wymyśliłem Chciałbym tylko zapytać tutaj i zobaczyć, co ludzie myślą.

Możliwe „wspólne” rozwiązania (p = przedrostek is = przyrostek):

  1. Format 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
    

    plusy:

    • Jest „powszechny”, więc „wystarczająco dobry” może być lepszy niż „najlepszy”.
    • Żadnych dziwnych postaci.
    • Łatwo odróżnić „obiekt blob daty / godziny” od wszystkiego innego.

    Cons:

    • Wersja tylko z datą nie jest łatwa do odczytania, a uwzględnienie czasu powoduje, że moje oczy krwawią, a sekundy to po prostu „lol”.
    • Zakłada 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
    

    plusy:

    • Bez odstępów.
    • Uwzględnia TZ.
    • Jest „niezły” do odczytania przez ludzi (tylko data jest w. Dobra).
    • Może być wygenerowany przez $ (data --iso = {godziny, minuty, sekundy})

    Cons:

    • scp / tar / etc. nie polubią tych znaków „:”.
    • Trochę czasu zajmuje „normalnym” ludziom zobaczenie WTF, do czego służy „T”, i na czym to polega na końcu :).
    • Wiele znaków „-”.
  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
    

    plusy:

    • Uwzględnia TZ.
    • Może być łatwo odczytany przez „wszystkich ludzi”.
    • Potrafi odróżnić datę / godzinę od prefiksu / sufiksu.
    • Niektóre z powyższych można wygenerować za pomocą $ (data --iso = {godziny, sekundy})

    Cons:

    • Ma spacje w wersjach czasowych (co oznacza, że ​​cały kod go nienawidzi).
    • scp / tar / etc. nie polubią tych znaków „:”.
  4. Uwielbiam łączniki:

    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
    

    plusy:

    • w zasadzie nieco ładniejszy syslog / etc. wariant.

    Cons:

    • Wiele znaków „-”.
    • Zakłada TZ.
  5. Uwielbiam łączniki z rozszerzeniami:

    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
    

    plusy:

    • w zasadzie nieco ładniejszy wariant „Uwielbiam łączniki”.
    • Żadnych dziwnych postaci.
    • Potrafi odróżnić datę / godzinę od prefiksu / sufiksu.

    Cons:

    • Za pomocą '.' tutaj jest nieco nietradycyjny.
    • Zakłada TZ.

... więc każdy chce podać preferencje i powód, lub więcej niż jeden (np. nie przejmuj się TZ, jeśli 95% pozostaje, aby pozostać maszyną lokalnie, ale dbaj bardzo, jeśli nie jest).

Lub oczywiście coś, czego nie ma na powyższej liście.



Jakie jest aktualne pytanie?
Totem - Przywróć Monikę

Myślałem, że moje pytanie brzmi bardziej „jaka jest najlepsza praktyka wykonywania XYZ”, a nie „jaka jest twoja ulubiona XYZ”, co, jak zakładam, było dozwolone?
James Antill,

Odpowiedzi:


19
  1. Format ISO 8601 powinien być przestrzegany w jak największym stopniu, ponieważ jest on najbliższy standardowi.
  2. „T” nie jest wystarczającą przeszkodą, aby naprawdę się go pozbyć.
  3. „:” Są potencjalnie zabójcami, więc należy ich unikać.
  4. Z powodów wymienionych w odpowiedziach innych osób należy zastosować czas UTC (lub „Z”).
  5. ISO 8601 zawiera format wykorzystujący UTC (czas „Z”), którego należy użyć.
  6. ISO 8601 zawiera format, który nie używa znaku „:”, którego należy użyć.

Więc ... próbuj „najlepsze” formaty daty i godziny:

  1. 20120317T1748Z

    • 100% zgodnie z ISO 8601
    • Tylko znaki alfanumeryczne (bardzo przyjazne dla sysadmin)
    • nie najszybszy do przeczytania, ale z pewnością czytelny dla laika
  2. 2012-03-17T1748Z

    • porcja daty jest zgodna z ISO 8601
    • przedział czasu jest zgodny z ISO 8601
    • przejście między datą a godziną jest zgodne z ISO 8601
    • łączy „rozszerzony” format ISO 8601 (data z łącznikami, czas ze średnikami) z podstawowym formatem ISO 8601 (data bez łączników, czas bez dwukropków), co prawdopodobnie nie jest całkiem właściwe
    • dodaje znak „-” (vs 1.)
    • troszkę łatwiej jest czytać laikowi (werset 1.)
  3. 17.03.2012 1748Z

    • porcja daty jest zgodna z ISO 8601
    • przedział czasu jest zgodny z ISO 8601
    • przejście między datą a godziną jest niezgodne z ISO 8601
    • łączy „rozszerzony” format ISO 8601 z „podstawowym” formatem ISO 8601
    • troszkę łatwiej jest czytać laikowi (w. 1. i 2.)
    • brak nowych postaci (vs 2.)

Jestem częściowy do 1., ponieważ jest to w pełni standard IAW, ale pozostałe są bliskie.

Uwaga :: Oczywiście dodaj sekundy, jeśli to konieczne. ... i tak, z sekundami lub bez (lub nawet minutami) to wszystko IAW ISO 8601. :)


2

Nie zawarłbym strefy czasowej, używam tylko czasu uniwersalnego. W przypadku pomyłki możesz dodać sufiks -UTC. Jeśli określisz strefę czasową, ktoś może na niej polegać. I byłyby dziwne przypadki, w których zmiany DST lub przesunięcia DST sieją spustoszenie w niektórych procesach lub przetwarzanie jest inne w niektórych systemach, ponieważ ich konfiguracja DST jest nieaktualna. UTC jest zawsze takie samo wszędzie.

Myślę, że łączniki sprawiają, że nazwa pliku jest bardziej czytelna w tym sensie, że ułatwia rozpoznanie czasu danych pliku. Jeśli chcesz uwzględnić dokładność poniżej sekundy, zwykle jest to .nnnnn.

Osobiście nie lubię T. Używanie dwukropka w nazwie pliku może wpływać na interoperacyjność z innymi systemami plików.


-1
  1. Ja także nie uwzględniałbym stref czasowych. Twoje skrypty / narzędzia przetwarzające dzienniki powinny o tym wiedzieć. Również w odniesieniu do zmian czasu letniego / zimowego - zalecam, aby twój serwer był zawsze ustawiony na UTC przez cały czas. Nagła różnica między strefą czasową serwera podstawowego a (niezmienioną) strefą czasową działającej na niej bazy danych może powodować bóle głowy ;-).

  2. Jeśli chodzi o nazewnictwo plików dziennika - wiem, wielu nie lubi tego, ale lubię to upraszczać:

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

plusy:

  • wspólny mianownik
  • bardzo łatwy w użyciu w dalszym skryptowaniu

Cons:

  • nieczytelne dla ludzi

Na komputerach, na których koledzy (z jakiegokolwiek powodu) muszą ręcznie sprawdzać dzienniki, wybrałem ten wariant, obracając codziennie:

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

Z poważaniem

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.