Формат позначки часу

Зміст:

• Підсумок
  • Проблема
  • Рішення
  • Статус
• Подробиці
  • Припущення
  • Обмеження
  • Позиції
  • Аргумент
  • Наслідки
• Пов’язане
  • Пов’язані рішення
  • Пов’язані вимоги
  • Пов’язані артефакти
  • Пов’язані принципи
• Примітки

Підсумок

Проблема

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

Ми взаємодіємо із системами, що мають різні формати позначок часу:

• Повідомлення JSON не мають вбудованого формату позначки часу, тому нам потрібно обрати, як перетворювати позначку часу на рядок і рядок на позначку часу, тобто як серіалізувати/десеріалізувати.

• Деякі застосунки налаштовано на використання місцевого часу, а не часу UTC. Це може бути зручно для проєктів, які мають підлаштовуватися під місцевий час, як-от проєкти, що запускають події на основі місцевого часу.

• Деякі системи мають різні потреби та можливості щодо точності часу, наприклад використовують роздільну здатність часу в секундах, мілісекундах чи наносекундах. Наприклад, команда date в операційній системі Linux за замовчуванням використовує точність часу в секундах, тоді як біржа Nasdaq хоче за замовчуванням точність часу в наносекундах.

Рішення

Ми обираємо стандартний формат позначки часу ISO 8601 з точністю до наносекунд, а саме «YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ».

Формат показує рік, місяць, день, годину, хвилину, секунду, наносекунди та часовий пояс Zulu, він же UTC, GMT.

Статус

Ухвалено.

Подробиці

Припущення

Нам потрібно обробляти ці текстові рядки позначок часу, щоб перетворювати позначку часу на рядок (він же серіалізація) і рядок на позначку часу (він же десеріалізація).

Ми хочемо формат, який загалом легкий у використанні, легкий для перетворення і легкий для читання людиною.

Ми хочемо сумісності з широким спектром зовнішніх систем, які ми не можемо контролювати, як-от системи аналітики, системи баз даних, фінансові системи.

Обмеження

Деякі системи мають обмеження точності часу. Наприклад, команда date в операційній системі macOS може виводити точність часу в секундах, але не в наносекундах.

Позиції

Ми розглянули низку варіантів:

• Епоха Unix, тобто одне число, що збільшується.

• Стислий текстовий формат «YYYYMMDDTHHMMSSNNNNNNNNN».

• Використання місцевого часового поясу чи часового поясу UTC.

Аргумент

Для типового використання ми цінуємо легкість читання/запису людьми більше, ніж чисту швидкість/розмір.

Для типового використання ми хочемо формат, який добре працює в машинних системах, а також добре працює вручну, як-от під час написання зразкових даних, читання виводу JSON, пошуку grep у файлі журналу тощо.

Для нетипового використання, як-от високопродуктивні обчислення, ми очікуємо, що захочемо оптимізувати будь-який обраний текстовий формат, перетворюючи текст на швидший формат, як-от вбудований тип об’єкта дати мови програмування. Тому текстовий формат для HPC не має великого значення.

Наслідки

Наші різні текстові системи та системи часу зійдуться на цьому форматі.

Пов’язане

Пов’язані рішення

Ми можемо захотіти швидкий/легкий спосіб також відстежувати часові різниці, він же тривалості. З позначками часу епохи Unix це легко.

Пов’язані вимоги

Ми можемо захотіти скоригувати наше рішення, напр., якщо матимемо пов’язану вимогу до певного виду мітки повідомлення журналу, як-от для Splunk, Sumo, ELK тощо.

Пов’язані артефакти

Форматувальники та аналізатори для мов програмування:

• date-fns: сучасна JavaScript-бібліотека утиліт для дат
• Crono: бібліотека дати й часу для Rust

Приклади Rosetta Code:

• Системний час
• Формат дати
• Показати епоху

Приклади SixArm:

• now_string

Пов’язані принципи

Легко скасовувати. Ми можемо досить легко перейти на інший формат, наприклад епоху Unix.

Відкладайте передчасну оптимізацію. Для типового використання нас не дуже турбує жменя зайвих символів, як-от формат із дефісами й двокрапками.

Примітки

Додайте примітки тут.