Календарный день не показывает точное время, а добавленная полночь не возвращает неизвестные сведения. Разбираем, какую подробность времени требует задача и что теряется при преобразовании.
Один день не отвечает на вопрос о порядке событий
Представим условный журнал доставки. Два заказа доставлены в один день, один утром, другой вечером. Для отчёта о числе доставок за день такой подробности может хватить. Но из одних календарных дат нельзя узнать, какой заказ привезли раньше и сколько времени прошло между доставками. Это уже другой вопрос к исходным сведениям.
Поэтому прежде, чем выбирать представление времени в базе, полезно сформулировать задачу словами. Нужен день, на который назначено событие, или время, когда оно действительно произошло? План и факт также различаются: дата обещанной доставки не становится временем её выполнения, даже если обе записи относятся к одному заказу и выглядят похоже в отчёте.
Что различает база данных
В документации PostgreSQL календарная дата описана отдельно от типов, содержащих и дату, и время суток. Временные отметки, в свою очередь, бывают с учётом часового пояса и без него. Тип хранит определённый вид значения, но назначение поля — например, план или факт доставки — всё равно должна определить команда.
Дата без времени подходит для значения, смысл которого связан именно с календарным днём. Дата вместе со временем позволяет описать более подробное событие. Чтобы однозначно говорить о моменте на общей временной шкале, нужен также корректный временной контекст. Одни часы и минуты без этого контекста не всегда обозначают единственный момент.
Добавленная полночь не восстанавливает точность
Допустим, условный источник сообщает только день доставки. При переносе приложение добавляет к нему время начала суток. Внешне запись стала подробнее, но новых сведений о реальном событии не появилось. Если затем считать длительность доставки по такой отметке, результат будет зависеть от принятого допущения, которое читатель отчёта может не заметить.
Предложим сохранять различие между известным временем и технически добавленным значением. Для обсуждения достаточно вопроса: откуда получены часы и минуты? Если их никто не измерял и источник их не передал, нельзя выдавать их за наблюдённый факт. Выбор удобного формата хранения не должен незаметно изменять степень уверенности в исходных данных.
Сворачивание времени в дату теряет часть информации
Обратная ситуация возникает, когда подробное время события превращают в календарную дату. В нашем журнале после такого перехода утренняя и вечерняя доставки оказываются одинаковыми по выбранному полю. Это может быть правильным действием для дневного итога, но восстановить утраченное время по готовому дню уже нельзя. Нужна исходная подробная запись.
Небольшой пример различий точности приведён в исторической записке Date and Time Formats, размещённой W3C: там отдельно рассматриваются полная дата и дата со временем. Это документ для обсуждения, а не новое обязательное требование. Для нашей задачи существенен сам выбор подробности, которую необходимо явно согласовать между источником и получателем.
Не путайте подробность с достоверностью
Большее число знаков после секунды не доказывает, что момент измерен с такой точностью. Источник мог округлить время раньше, получить его из другой системы или сообщить лишь момент регистрации записи. Для условной доставки нужно отдельно различать время самого события и время поступления сообщения о нём. Они отвечают на разные вопросы о процессе.
Для учебного разбора предложим описать три поля словами: назначенный день, фактическое время доставки и время получения сообщения. Затем выбрать, какое поле подходит для каждого вопроса отчёта. Так можно заметить смысловую ошибку ещё до вычислений. Полный разбор часовых поясов и правил границ отчётного месяца — отдельные темы; они не заменяют определения смысла поля.
С чего начать знакомство с временными данными
В разговоре со специалистом попросите объяснить, что известно источнику и какая информация теряется при каждом переходе. Как задавать вопросы к таблицам, рассказывает введение в SQL. А совместное сохранение связанных изменений рассматривает статья о транзакциях; правильный тип времени сам по себе этого не обеспечивает.
Продолжить работу с таблицами можно на курсе «SQL инженер». Полезный первый результат — выбрать нужную подробность для конкретного вопроса и объяснить, почему календарный день нельзя автоматически считать точным временем события.
