Бажаний формат імен файлів, що містять часову позначку

Як ми всі знаємо, "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
   

   плюси:

   • Це "звичайно", тому "досить хороший" може бути кращим, ніж "найкращий".
   • Ніяких дивних персонажів.
   • Легко відрізнити "крапку дати / часу" від усього іншого.

   мінуси:

   • Версію лише з датами читати непросто, і враховуючи час, у мене очі кровоточать, а секунди також просто "хаха".
   • Припускає TZ.

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
   

   плюси:

   • Пробілів немає.
   • Враховує ТЗ.
   • Чи не "погано" для читання людьми (тільки дата - це проти).
   • Може бути створено $ (дата --iso = {годин, хвилин, секунд})

   мінуси:

   • scp / tar / тощо. не сподобаються ці символи ':'.
   • Потрібно трохи "нормальним" людям побачити WTF, що "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
   

   плюси:

   • Враховує ТЗ.
   • Легко можна прочитати «всіма людьми».
   • Можна відрізнити дату / час від префікса / суфікса.
   • Деякі з перерахованих вище можна створити за допомогою $ (дата --iso = {годин, секунд})

   мінуси:

   • Має пробіли у часових версіях (це означає, що весь код буде ненавидіти його).
   • 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
   

   плюси:

   • в основному трохи приємніший syslog / тощо. варіант.

   мінуси:

   • Багато символів "-".
   • Припускає TZ.

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.

... тож кожен хоче надати перевагу та причину, або більше, ніж один (напр., не хвилюється TZ, якщо це 95 +%, щоб залишатись локальним автоматом, але важливо багато, якщо його немає).

Або, очевидно, щось не вказано у переліченому списку.

1. Формат ISO 8601 слід максимально дотримуватися, оскільки це найближче до стандарту.
2. "T" не є достатнім каменем спотикання, щоб дійсно вимагати позбавлення від нього.
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

З повагою