Назад | Перейти на главную страницу

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

Как мы все знаем, в файле "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

    плюсы:

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

    минусы:

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

  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

    плюсы:

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

    минусы:

    • scp / tar / и т. д. не понравятся эти символы ":".
    • «Нормальным» людям требуется немного времени, чтобы увидеть, для чего нужна буква «T» и что это за штука в конце :).
    • Множество символов "-".

  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})

    минусы:

    • В версиях времени есть пробелы (что означает, что весь код будет его ненавидеть).
    • scp / tar / и т. д. не понравятся эти символы ":".

  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

    плюсы:

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

    минусы:

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

  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

    плюсы:

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

    минусы:

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

... так что любой хочет указать предпочтение и причину, или более одной (например, не заботьтесь о TZ, если 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. Использование двоеточия в имени файла может повлиять на совместимость с другими файловыми системами.

Как бы то ни было, это формат, который утилита скриншотов scrot по умолчанию используется для имени файла (т. е .: если имя файла не указано):

%Y-%m-%d-%H%M%S_$wx$h_scrot.png

Детали, использующие % являются стандартными strftime(3) спецификаторы формата, $w ширина изображения и $h высота изображения.

Пример:

$ scrot
$ find *.png
2020-03-07-152236_1920x1080_scrot.png

Для меток времени UTC:

$ TZ=UTC scrot
$ find *.png
2020-03-07-152236_1920x1080_scrot.png
2020-03-07-183257_1920x1080_scrot.png

Заметка: Часовой пояс не указан в имени файла. Учитывая предназначение инструмента (например, скриншоты), я не думаю, что это принесет пользу. Кроме того, я считаю, что приведенный выше формат достаточно прост как для чтения, так и для анализа.

Источник:

if (!opt.output_file) {
  opt.output_file = gib_estrdup("%Y-%m-%d-%H%M%S_$wx$h_scrot.png");
  opt.thumb_file = gib_estrdup("%Y-%m-%d-%H%M%S_$wx$h_scrot-thumb.png");
} else {
  have_extension = scrot_have_file_extension(opt.output_file);
}

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

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

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

плюсы:

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

минусы:

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

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

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

С уважением