Предпочтительный формат имен файлов, которые включают метку времени

Как мы все знаем, «unix» может иметь в файле что угодно, кроме «/» и «\ 0», однако системные администраторы, как правило, имеют гораздо меньшее предпочтение, в основном из-за того, что в качестве входных данных не используются пробелы ... и куча вещей, имеющих особое значение для «:» и «@» среди других.

Недавно я видел еще один случай, когда в имени файла использовалась временная метка, и после того, как я немного поиграл с разными форматами, чтобы сделать ее «лучше», я решил, что попытаюсь найти «лучшую практику», а не ту, которую я вычислил. Я бы просто спросил здесь и посмотреть, что думают люди.

Возможные «общие» решения (p = префикс и s = суффикс):

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

   плюсы:

   • Это «обычный», так что «достаточно хороший» может быть лучше, чем «лучший».
   • Никаких странных персонажей.
   • Легко отличить «каплю даты / времени» от всего остального.

   минусы:

   • Версия только для даты не легка для чтения, и, учитывая время, мои глаза кровоточат, а секунды - это просто "смеется".
   • Предполагает ТЗ.

2. 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
   

   плюсы:

   • Пробелов нет
   • Принимает во внимание ТЗ.
   • «Неплохо» для чтения людьми (дата только v. Хорошо).
   • Может быть сгенерировано $ (date --iso = {часы, минуты, секунды})

   минусы:

   • УПП / смола / и т.д.. не понравятся эти символы ':'.
   • «Нормальным» людям нужно немного, чтобы увидеть WTF, для которого «Т», и что это за вещь в конце :).
   • Много символов «-».

3. формат 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
   

   плюсы:

   • Принимает во внимание ТЗ.
   • Может быть легко прочитано «всеми людьми».
   • Может отличить дату / время от префикса / суффикса.
   • Некоторые из вышеперечисленных могут быть сгенерированы с помощью $ (date --iso = {hours, seconds})

   минусы:

   • Имеет пробелы во временных версиях (что означает, что весь код будет ненавидеть это).
   • УПП / смола / и т.д.. не понравятся эти символы ':'.

4. Я люблю дефисы:

   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
   

   плюсы:

   • в основном немного более приятный системный журнал / и т.д. вариант.

   минусы:

   • Много символов «-».
   • Предполагает ТЗ.

5. Я люблю дефисы с расширениями:

   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
   

   плюсы:

   • в основном немного более хороший вариант "я люблю дефисы".
   • Никаких странных персонажей.
   • Может отличить дату / время от префикса / суффикса.

   минусы:

   • С помощью '.' здесь несколько нетрадиционно.
   • Предполагает ТЗ.

... так что любой хочет дать предпочтение и причину, или более чем одну (например, ТЗ не заботится о том, чтобы 95% оставалось локальным на машине, но очень важно, если это не так).

Или, очевидно, что-то не в списке выше.

1. Формат ISO 8601 должен соблюдаться в максимально возможной степени, поскольку он является наиболее близким к стандарту.
2. Буква «Т» не является камнем преткновения, чтобы действительно избавиться от него.
3. ':' Являются потенциально убийцами, поэтому их следует избегать.
4. По причинам, указанным в ответах других, следует использовать UTC (или время «Z»).
5. ISO 8601 включает формат с использованием UTC (время 'Z'), который следует использовать.
6. ISO 8601 включает формат, в котором не используется символ «:», который следует использовать.

Итак ... примеры «лучших» форматов даты и времени:

1. 20120317T1748Z

   • 100% в соответствии с ISO 8601
   • только буквенно-цифровые символы (очень дружественные к системным администраторам)
   • не самый быстрый для чтения, но непременно читаемый для непрофессионала

2. 2012-03-17T1748Z

   • часть даты соответствует ISO 8601
   • часть времени соответствует ISO 8601
   • переход между датой и временем соответствует ISO 8601
   • смешивает расширенный формат ISO 8601 (дата с дефисами, время с двоеточиями) с базовым форматом ISO 8601 (дата без дефисов, время без двоеточий), что, вероятно, не совсем верно
   • добавляет символ «-» (против 1.)
   • непрофессионалу немного легче читать (против 1.)

3. 2012-03-17--1748Z

   • часть даты соответствует ISO 8601
   • часть времени соответствует ISO 8601
   • переход между датой и временем не соответствует ISO 8601
   • смешивает расширенный формат ISO 8601 с базовым форматом ISO 8601
   • непрофессионалу немного легче читать (стихи 1. и 2.)
   • нет новых персонажей (против 2.)

Я неравнодушен к 1. Так как это полностью IAW стандарт, но остальные близки.

Примечание :: Конечно, добавляйте секунды по мере необходимости. ... и да, с или без секунд (или даже минут) - это все IAW ISO 8601. :)

Я бы не включал часовой пояс, только использовал универсальное время. Если может возникнуть путаница, вы можете добавить суффикс -UTC. Если вы указываете часовой пояс, кто-то может зависеть от него. И были бы странные крайние случаи, когда изменения DST или сдвиги DST приводили к хаосу при некоторой обработке, или обработка отличалась в некоторых системах, потому что их конфигурация DST не актуальна. UTC всегда везде одинаков.

Я действительно думаю, что дефисы делают имя файла более читабельным, в том смысле, что оно облегчает распознавание даты и времени данных файла. Если вы хотите включить точность до секунды, то обычно это .nnnnn.

Мне лично не нравится T. Использование двоеточия в имени файла может повлиять на совместимость с другими файловыми системами.

1. Я бы тоже не включил часовые пояса. Ваши скрипты / инструменты, которые обрабатывают журналы, должны знать об этом. Также в отношении изменений летнего / зимнего времени - я бы рекомендовал постоянно поддерживать ваш сервер в UTC. Внезапная разница между часовым поясом базового сервера и (неизменным) часовым поясом работающей на нем базы данных может привести к головным болям ;-).

2. Что касается имен файлов журналов - я знаю, многим это не нравится, но я бы хотел, чтобы все было просто:

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

плюсы:

• общий знаменатель
• очень прост в использовании в дальнейшем сценарии

минусы:

• не читаемый человеком

На машинах, где коллегам (по какой-либо причине) необходимо проверять журналы вручную, я использовал этот вариант, ежедневно меняясь:

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

С наилучшими пожеланиями