Типові помилки при роботі з датами та часом

Сьогодні знову поговоримо про фейли. Бо працювати з датами та часом — це як ходити по мінному полю: все ок, поки не зробиш перший крок не туди.

Помилки при виборі типу даних

Тут часто і починаються всі проблеми. Неправильний вибір типу даних може звести нанівець всі твої старання з датами та часом.

Ситуація 1: Використання DATE замість TIMESTAMP

Коли ти фіксуєш подію, яка має не лише дату, а й час, використання тільки DATE може призвести до втрати важливої інфи.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- тільки дата
);

З таким дизайном ти не дізнаєшся, чи було зроблено два замовлення зранку чи ввечері. Навіщо взагалі втрачати можливість попити каву і подивитись на красиві часові мітки?

Ситуація 2: Забули про часові зони

Якщо твій додаток працює з юзерами з різних країн, але ти зберігаєш дату і час просто через TIMESTAMP, без урахування часових поясів, твої дані можуть стати "безхатченками". TIMESTAMPTZ вирішує цю проблему за тебе.

CREATE TABLE events (
    event_time TIMESTAMP -- без часової зони
);

Ніхто не хоче переплутати вечірню подію в Нью-Йорку з ранковою в Токіо. Використовуй TIMESTAMPTZ!

Помилки при використанні функцій

Ситуація 1: Неправильний формат у TO_CHAR()

Проблеми починаються, якщо ти неправильно вкажеш формат. Наприклад:

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Ой, переплутав місяць і день

Тут замість звичного рік-місяць-день, ми отримали рік-день-місяць. Це може призвести до кумедних (але не завжди приємних) ситуацій для твоїх юзерів. Завжди перевіряй формат.

Ситуація 2: Помилки при використанні TO_DATE()

Навпаки, якщо ти намагаєшся перетворити рядок у дату, але формат не співпадає, PostgreSQL видасть помилку.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- Помилка! Формат не співпадає.

Формат рядка має чітко відповідати тому, що ти вказав. Наприклад:

SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- Все ок.

Помилки з часовими інтервалами

Ситуація 1: Неявне приведення типів

Іноді можна забути про особливості приведення типів. Наприклад:

SELECT NOW() + '1'; -- ПОМИЛКА! Незрозуміло, що таке '1'.

PostgreSQL не розуміє, що ти хочеш додати один день. Правильний спосіб:

SELECT NOW() + INTERVAL '1 day';

Ситуація 2: Плутанина з відніманням інтервалів

Будь уважний, додаючи або віднімаючи інтервали:

SELECT NOW() - INTERVAL '-1 day'; -- Це додасть день замість віднімання!

Тут подвійний мінус створює протилежний ефект. Краще уникати таких конструкцій.

Помилки при округленні та обрізанні даних

Ситуація 1: Неправильне обрізання з DATE_TRUNC()

Коли ти використовуєш DATE_TRUNC() для групування даних, завжди перевіряй, чи точно вибрав потрібний рівень. Наприклад:

SELECT DATE_TRUNC('hour', NOW()); -- Обрізає до початку години
SELECT DATE_TRUNC('minute', NOW()); -- Обрізає до початку хвилини

Якщо ти очікував один результат, а отримав інший, можливо, вибрав не той рівень.

Ситуація 2: Забув про часові зони з DATE_TRUNC()

Якщо ти працюєш з часом у різних часових зонах, результат може бути неочікуваним:

SELECT DATE_TRUNC('day', NOW() AT TIME ZONE 'UTC');

Переконайся, що часова зона вказана правильно, інакше можна реально загубитись у часі.

Unix-час: втрачені секунди

Unix-час (EPOCH) — штука зручна, але підступна. Найпоширеніша помилка — плутанина між секундами і мілісекундами.

SELECT TO_TIMESTAMP(1680000000); -- Це правильно (секунди).
SELECT TO_TIMESTAMP(1680000000000); -- Це помилка! Забагато нулів.

Перевіряй, у чому вимірюється твій таймстамп, щоб не зберігати мільйон зайвих секунд.

Помилки з часовими зонами

Ситуація 1: Плутанина з часовими зонами

Коли ти працюєш з юзерами з різних часових поясів, дані можуть змішуватись. Наприклад:

SELECT TIMESTAMP '2023-10-01 10:00:00' AT TIME ZONE 'UTC';

Переконайся, що ти чітко розумієш, у якій часовій зоні знаходяться дані.

Ситуація 2: Дублювання часових зон

Записувати дату з часом і потім ще раз враховувати часові зони — погана ідея:

SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- Не роби так!

Це може призвести до неправильних розрахунків.

Рекомендації для уникнення помилок

Обирай правильний тип даних. Якщо працюєш з міжнародними часовими даними, використовуй TIMESTAMPTZ. Якщо достатньо лише дати — зупинись на DATE.

Тестуй свої запити. Переконайся, що результати відповідають очікуванням, особливо якщо працюєш з інтервалами, форматами чи округленням.

Зберігай часові дані в UTC. Це найкращий спосіб уникнути плутанини з часовими зонами.

Перевіряй формати. Переконайся, що формат у TO_CHAR() і TO_DATE() відповідає твоїм даним.

Використовуй функції обережно. Уважно читай документацію PostgreSQL по часовим функціям, щоб уникнути неочікуваних сюрпризів.

Робота з часовими даними може бути непростою, але з правильним підходом і увагою до деталей все буде максимально гладко. Дати і час — важлива частина твоїх додатків, і забути про це так само небезпечно, як забути поставити будильник на ранок понеділка!