Даты переноса как метка времени Unix Epoch

Question

Некоторое время назад я работал над конкретным проектом, используя Spring на бэкэнде. Система должна работать в нескольких часовых поясах. Поэтому было решено использовать целочисленные значения (Long) для хранения и переноса дат между сервером и веб-приложением. Как я помню, основной причиной было упрощение и минимизация работы с часовыми поясами, поскольку временная метка всегда будет представлять точное время, и мы всегда можем извлечь из нее дату, не беспокоясь о неправильном часовом поясе (браузер пользователя будет применять правильный часовой пояс).

В то время я мало занимался архитектурой, так как был всего лишь младшим. Но с тех пор я не видел никакого применения этой практики, и я ничего не могу найти в Интернете.

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

Поэтому я хотел бы знать, есть ли реальная выгода от использования числовых временных меток?

Я вижу по крайней мере два потенциальных преимущества:

• Меньше хлопот с часовыми поясами (особенно для менее опытных разработчиков, которые могут запутаться при работе с датами)
• Меньше данных передается через REST (?)

Недостатки:

• Мы должны извлекать значение даты каждый раз, чтобы обрабатывать или отображать его (это может быть автоматизировано с использованием большинства сред внешнего интерфейса)
• Значения базы данных и серверотладка не так очевидна

Answer 1

Под сценами типов DATE в базах данных и языках более высокого уровня всегда есть некоторая версия относительного смещения даты и разрешения. Например:

• DOS использовал 1 января 1980 года с 10 мс,
• COBOL предполагал 1 января 1601 года с разрешением 1 с
• UNIX и его аналог, как оказалось, выбрал 1 января1970 полночь по Гринвичу.

Преимущества использования числовых и не интерпретированных чисел в вашем хранилище данных, возможно, (но субъективно) упрощают арифметику дат. Для TZ-материалов, таких как планирование / логистика авиакомпаний, основанное на числовом (против типа даты) качестве числового собственного, позволяет сохранить согласованность без преобразований функций типа даты, несмотря на TZ, а также политически произвольные корректировки DST . Потому что Акт Единого Времени является самой отдаленной вещью из однородности.

Answer 2

Я бы сказал, что это действительно зависит от целевого использования этого значения. Вероятно, было бы более разумно представить значение метки времени, если вы ожидаете технического использования, и ISO 8601 , если вы ожидаете какого-либо другого использования. В большинстве случаев они, вероятно, были бы синонимами (не обращайте внимания на дополнительные секунды). Они оба относятся к фиксированному моменту времени.

Отображение дат в виде строк ISO 8601 определенно легче для отладки и для человеческого глаза. Вы сразу знаете, какой это момент времени.

Временные метки UNIX исторически также имели недостаток ограничения размера целочисленных значений. В 64-битной архитектуре это обычно больше не является проблемой, но для обратной совместимости лучше было бы использовать строки обратной совместимости.

Я бы определенно не рекомендовал выставлять даты через API в местных часовых поясах. Такие значения обычно неоднозначны и ненадежны. Они хороши для людей, но не хороши ни для чего другого. Рассмотрим летнее время, например. Некоторые периоды времени существуют дважды, а некоторые часы вообще не существуют.