Формат на времеви печат

Съдържание:

• Резюме
  • Проблем
  • Решение
  • Състояние
• Подробности
  • Допускания
  • Ограничения
  • Позиции
  • Аргумент
  • Последици
• Свързани
  • Свързани решения
  • Свързани изисквания
  • Свързани артефакти
  • Свързани принципи
• Бележки

Резюме

Проблем

Искаме да можем да проследяваме кога се случват нещата с помощта на времеви печати и последователен формат на времевите печати, който работи добре във всички наши системи и системите на трети страни.

Взаимодействаме със системи, които имат различни формати на времеви печати:

• Съобщенията в 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: Modern JavaScript date utility library
• Crono: date and time library for Rust

Примери от Rosetta Code:

• System time
• Data format
• Show the epoch

Примери от SixArm:

• now_string

Свързани принципи

Лесно обратимо. Можем доста лесно да преминем към различен формат, като Unix епоха.

Отложете преждевременната оптимизация. За типична употреба не ни пука много за шепа допълнителни знаци, като формат, който използва тирета и двоеточия.

Бележки

Добавете бележки тук.