Формат временной метки

Содержание:

Резюме
Подробности
Связанное
Примечания

Резюме

Проблема

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

Мы взаимодействуем с системами, у которых разные форматы временных меток:

У сообщений 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 и т. д.

Связанные артефакты

Форматировщики и парсеры для языков:

Примеры Rosetta Code:

Примеры SixArm:

now_string

Связанные принципы

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

Откладывайте преждевременную оптимизацию. Для типичного использования нас мало волнует несколько лишних символов, например в формате с дефисами и двоеточиями.

Примечания

Добавьте примечания здесь.