Ниже приведён системный обзор механики работы с датами в CMF Cotonti на основе структуры таблицы cot_pages и набора функций обработки времени из ядра. Материал построен от частного к общему: от конкретных полей базы данных — к логике хранения, конвертации, вывода и импорта. Текст ориентирован на начинающих разработчиков и администраторов.

Даты в CMF Cotonti

Запись, хранение и вывод (представление)

Работа с датами в Cotonti построена на одном принципе: в базе данных хранятся не строковые даты, а UNIX-временные метки (timestamp).

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

1. Как устроено хранение дат в таблице cot_pages

В таблице страниц используются поля:

• page_date

• page_begin

• page_expire

• page_updated

Все они имеют тип:

Это означает:

• Хранится целое число

• Это количество секунд с 1 января 1970 года 00:00:00 (UTC)

• Никаких строк формата YYYY-MM-DD в этих полях быть не должно

Пример реальных значений из базы:

Если перевести их в привычный формат, получится:

• 1639236600 → 11.12.2021 10:30:00

• 1699716120 → 11.11.2023 09:02:00

• 1704948992 → 11.01.2024 12:16:32

• 0 → дата не задана

Значение 0 в Cotonti означает отсутствие даты или отсутствие ограничения.

2. Общая схема работы с датой в Cotonti

Любая дата проходит 5 этапов:

1. Ввод (строка от пользователя или из файла)

2. Конвертация в timestamp

3. Сохранение в INT поле БД

4. Выборка из БД

5. Форматирование для вывода с учётом языка и часового пояса

Рассмотрим подробно.

3. Ввод даты: строковое представление

Пользователь может ввести:

или

или

На этом этапе дата — это строка. Она ещё не пригодна для хранения в Cotonti.

4. Конвертация строки в UNIX timestamp

В ядре используется функция cot_date2stamp().

Она:

• Проверяет пустые значения

• Проверяет специальные строки

• Возвращает UNIX timestamp

• Возвращает NULL, если дата некорректная

Пример логики без углубления в код:

Вход:

Выход:

Если вход:

Выход:

Если вход:

Выход:

Это критически важное поведение.

5. Хранение в базе данных

После конвертации значение записывается в поле типа INT.

Пример записи:

База данных:

• Может сортировать по числам быстрее

• Может сравнивать даты через обычные операции

• Не зависит от формата строки

• Не зависит от локали

Например:

Это простой числовой диапазон.

Если бы хранились строки, логика была бы сложнее и менее надёжной.

6. Вывод даты пользователю

Для отображения используется функция cot_date().

Она:

1. Принимает timestamp

2. При необходимости добавляет смещение часового пояса пользователя

3. Форматирует дату

4. Заменяет английские названия месяцев на локализованные

Пример.

В базе хранится:

Серверное время — UTC.

Пользователь в часовом поясе +3.

Функция добавит:

И пользователь увидит:

Таким образом:

• Хранение всегда нейтральное (UTC)

• Отображение — персонализированное

7. Примеры полного жизненного цикла даты

Сценарий 1 — обычная публикация

Пользователь вводит:

Система преобразует в:

В базе хранится:

При выводе:

Сценарий 2 — отложенная публикация

Ввод:

Timestamp:

Запись:

Пока текущий timestamp меньше этого значения — страница скрыта.

Сценарий 3 — бессрочная публикация

Значит:

• Страница не имеет даты окончания

Сценарий 4 — обновление страницы

При редактировании:

Это фиксирует момент изменения.

8. Почему нельзя хранить '0000-00-00'

Это принципиально важный момент.

Причины:

1. Поля типа INT

В cot_pages нет полей DATE или DATETIME.
Хранение строки приведёт к:

• неявному преобразованию

• ошибке

• значению 0

2. Ядро специально блокирует такие значения

Функция преобразования возвращает NULL для:

• 0000-00-00

• 0000-00-00 00:00:00

• 0000-00-00 00:00

Это сделано намеренно.

3. Логическая ошибка

Дата:

Не является валидной датой в реальном времени.

Она:

• не участвует в корректном сравнении

• не имеет timestamp

• не может быть отображена корректно

4. STRICT режим MySQL

Современные версии MySQL запрещают такие значения в режиме STRICT.

5. Нарушение логики публикации

Если page_begin = 0, это "нет ограничения".
Если бы там было 0000-00-00, поведение стало бы непредсказуемым.

9. Почему нельзя использовать '0000-00-00' при импорте CSV/Excel

При импорте CSV:

• Все данные — строки

• Далее происходит преобразование

Если в CSV указано:

то:

1. Преобразование вернёт NULL

2. В БД может попасть 0

3. Публикация может работать неправильно

4. Сортировка будет нарушена

5. Возможны ошибки массового импорта

Excel дополнительно может:

• заменить 0000-00-00 на 0

• интерпретировать дату некорректно

• удалить ведущие нули

Это создаёт скрытые ошибки.

10. Как правильно готовить даты для импорта

Лучший способ — использовать сразу UNIX timestamp.

Пример строки CSV:

Это гарантированно корректный формат.

11. Как конвертировать строковую дату в timestamp

Через Excel

Если в ячейке дата:

Формула:

Результат:

Важно:

• Формат ячейки должен быть "Числовой"

• Нужно округлить до целого

Через PHP

или через функцию Cotonti:

Через онлайн-конвертер

Можно использовать любой UNIX timestamp converter.

12. Можно ли конвертировать '0000-00-00' в timestamp?

Нет.

Это не реальная дата.

Единственно корректные варианты:

• заменить на 0

• заменить на реальную дату

• оставить пустым

Нельзя получить валидный timestamp из несуществующей даты.

13. Обратная конвертация timestamp → дата

Если в базе:

Можно получить:

При отображении Cotonti дополнительно:

• учтёт часовой пояс

• выполнит локализацию месяцев

• отформатирует по шаблону

14. Рекомендации по работе с датами

1. Всегда храните дату как INT.

2. Для отсутствия даты используйте 0.

3. Никогда не используйте 0000-00-00.

4. При импорте готовьте timestamp заранее.

5. Проверяйте часовой пояс.

6. Не храните строки в полях INT.

15. Полная архитектурная логика

Почему Cotonti использует timestamp:

• Универсальность

• Быстрое сравнение

• Независимость от формата

• Простота экспорта/импорта

• Минимизация ошибок локализации

• Простота работы с часовыми поясами

Это классическая и надёжная модель хранения времени.

Заключение

Работа с датами в Cotonti построена на строгом принципе:

Хранение — только UNIX timestamp (INT).
Строка — только для ввода и вывода.

Использование:

• 0000-00-00

• 0000-00-00 00:00:00

• 0000-00-00 00:00

недопустимо ни в базе, ни в CSV.

При импорте всегда приводите дату к timestamp.
При отсутствии даты используйте 0.
При выводе доверяйте функции форматирования.

Понимание этой схемы полностью снимает проблемы с публикацией, сортировкой, временными ограничениями и локализацией в Cotonti.