У змінній a лежить datetime(2026, 3, 28, 14, 5) без пояса, у b — той самий запис із tzinfo=ZoneInfo("Europe/Kyiv"). Що станеться при a < b?
Чому так. Наївний момент не позначає точки на світовій осі часу, тому питання «який раніший» не має відповіді — і Python зупиняє програму замість того, щоб вгадати. Спокуслива відповідь про «однаковий час» описує поведінку ==, який справді не кидає помилки, а тихо повертає False.
Питання 2 / 8
Чому datetime.utcnow() оголосили застарілим у Python 3.12?
Чому так. Рахував він бездоганно — проблема в тому, що результат мовчав про власний пояс. Такий обʼєкт мовчки порівнюється з наївним місцевим часом і зсуває мітку при .timestamp(). Сучасна заміна — datetime.now(timezone.utc), де пояс написаний прямо в обʼєкті.
Питання 3 / 8
Момент 28.03.2026 14:05 за київським часом, і до нього додали timedelta(days=1). Наступної доби Київ переходить на літній час. Що покаже результат і скільки минуло насправді?
Чому так. Арифметика над обізнаним моментом настінна: Python додає одиницю до поля «день», лишає циферблат на 14:05 і лише потім перераховує зміщення. Доба 29 березня має 23 години, тому фізично минуло 23. Варіант із 15:05 дає інший спосіб — додавання 24 годин у UTC, і він теж правильний, але відповідає на інше запитання.
Питання 4 / 8
Чому в timedelta немає аргументів months і years?
Чому так. Місяць буває 28, 29, 30 або 31 день, тому «31 січня плюс місяць» не має єдиної правильної відповіді — це календарна операція, а не відстань. Останній варіант спокусливий, але хибний по суті: timedelta зберігає дні, секунди й мікросекунди, і день у ньому цілком є.
Питання 5 / 8
У журналі лежать текстові дати 28.03.2026, 02.11.2025 і 31.12.2024. Що дасть sorted() над цим списком рядків?
Чому так. Сортування рядків посимвольне: перший символ у записі дд.мм.рррр — це день місяця, тому список шикується за днем, а роки перемішуються. Хронологічний порядок вийшов би лише з ISO-запису рррр-мм-дд, де старший розряд стоїть першим і всі поля мають сталу ширину.
Питання 6 / 8
Один і той самий момент записали в чотирьох поясах через astimezone. Що спільного в цих чотирьох обʼєктів?
Чому так.astimezone не рухає мить — він переписує її іншим циферблатом, тому .timestamp() у всіх чотирьох збігається до частки секунди. Змінюються саме поля годин і зміщення: у Токіо буде 21:05 +09:00 там, де в Києві 14:05 +02:00.
Питання 7 / 8
Шаблон "%d.%m.%Y" застосували до моменту 2026-03-28 14:05:09, а потім розібрали отриманий рядок тим самим шаблоном через strptime. Що вийде?
Чому так. Шаблон не містить кодів часу, тож у рядок він не потрапив — а звідки його немає, звідти й не відновиться. strptime мовчки підставляє нулі: помилки не буде, момент просто стане іншим. Саме тому дд.мм.рррр — формат показу, а зберігати треба в ISO.
Питання 8 / 8
Де правильно зберігати мітки часу в базі даних і чому?
Чому так. Правило «зберігай у UTC, показуй у місцевому» знімає цілий клас помилок «на годину»: у UTC немає що зсувати, тож тривалості й порівняння рахуються чесно. Мітка в місцевому поясі ламається саме тоді, коли її перерахували вже після переходу — і зміщення виявилось іншим, ніж у момент запису.