#architecture
Одна зі стандартних вимог для глобальних веб-проектів – це підтримка часових поясів.
1️⃣ Для полегшення архітектури краще використовувати такий поділ відповідальності:
👉 Веб сервер відповідає за обробку та передачу даних в UTC.
👉 Веб клієнт відповідає за відображення date-time у необхідній користувачеві таймзоні та календарі. Нагадаю, що існують країни, які використовують не Григоріанський календар.
⚠️ цей підхід не прибирає потреби у сервера працювати з часовими поясами.
2️⃣ Визначається точність виміру часу. Стандартно це мілісекунди.
3️⃣ Визначається dto serialization (формат передачі у API) для таких сутностей
👉 момент часу. Unix Timestamp (
1675096836070) або рядок у форматі ISO 8601 (2023-01-30T16:37:12.661Z)👉 часовий пояс. Ім'я (
Europe/Kyiv)👉 конкретна дата. ISO 8601(
2023-01-30) або момент часу коли почалась ця дата або як інтервал часу.👉 Тривалість. ISO 8601 format (
12H30M5S) або кількість мілісекунд.👉 Інтервал часу. Як два моменти часу (початок та кінець), або як початок та тривалість, або як один рядок (
2023-01-01T13:00:00Z/2023-01-01T15:30:00Z)Всі прийняті рішення є частиною специфікації вашого API
4️⃣ Визначається на рівні коду або на рівні бази даних відбуватиметься маніпуляція з datetime та timezone. Приклад: клієнт запитує транзакції користувача за
2023-01-30 у таймзоні Europe/Kyiv. Особисто я перекладаю відповідальність фільтації на базу даних.