Дата без часового пояса

Строка 2026-03-01 описывает календарную дату. Она подходит для дня рождения дерева в каталоге наблюдений или отчётного дня, если время суток несущественно. Преобразование такой даты в полночь UTC добавляет сведения, которых в исходнике не было. Позднее интерфейс может перевести полученный момент в другой пояс и показать предыдущий день.

Строка 2026-03-01T12:00:00 без смещения задаёт местные часы, но не единственный момент на временной шкале. Для события, которое должно произойти одновременно для всех участников, нужны UTC или смещение с ясными правилами. Для будущего регулярного расписания часто нужен ещё и идентификатор часовой зоны, потому что фиксированное смещение не описывает изменения правил.

Смещение +03:00 говорит, сколько нужно прибавить к UTC для этого представления. Название зоны описывает набор правил, действовавших и ожидаемых в разные даты. Это разные виды метаданных. Сохранение только смещения достаточно для уже наблюдённого момента, но может быть недостаточно для повторяющегося события «каждый день в девять по местному времени».

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

Unix timestamp требует единицы измерения: секунды, миллисекунды и микросекунды легко перепутать. Число без единицы и эпохи не является полным контрактом. Зафиксируйте также допустимый диапазон и точность. При переводе через float доли секунды могут округлиться, поэтому для точных значений полезны целые единицы или десятичное текстовое представление.

Лексикографическая сортировка ISO-подобных строк совпадает с хронологией только при согласованном представлении. Разные смещения, разная точность и необязательные компоненты могут нарушить ожидание. Для сравнения моментов сначала разберите значения и приведите к общей шкале. Исходную запись сохраните, если её пояс или точность имеют самостоятельное значение.

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

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

В Python различайте naive и aware datetime. Наличие объекта datetime ещё не означает, что зона известна. Для реального времени журнала используйте timezone.utc и сохраняйте явное смещение. Даты материалов этого сайта хранятся отдельно как редакционные календарные даты; сборка не обновляет их по часам сервера.

В схеме назовите поле по смыслу: observed_at для момента наблюдения и report_date для отчётного дня. Опишите источник зоны, политику неопределённых значений и обработку ошибочных дат. Если старый набор содержит местные даты без зоны, не изобретайте UTC задним числом. Сначала установите происхождение, а неустранимую неопределённость отразите в метаданных и ограничениях результата.