Устанавливать ли в php таймзону пользователя?

Question

[Михаил]

Привет.
Прочел достаточно статей на тему, примерно понял систему, что храним в UTC, но хотел бы пару моментов уточнить.

Сервер, например, работает в Москве, а его пользователи по всей стране. Каждый пользователь в своем личном кабинете может установить себе личную временную зону (ЛВЗ далее) .

Такие вопросы:
1) В php приложении, в бутстрапе, не стоит в date_default_timezone_set() устанавливать эту ЛВЗ пользователя? Т.к. это будет аффектить все другие подсистемы, типа логов.

2) В БД, mysql, установка временной зоны по умолчанию в UTC считается нормой?

3) Использовать ли тип TIMESTAMP, который хранит в базе время в UTC (что и хотели), а временную зону в БД будем в бутстрапе устанавливать в значение равное ЛВЗ пользователя? Дата будет прилетать в базу, как клиент ввел.
Но если учесть пункт 1), то зоны в разных частях приложения будут отличаться.

4) Может использовать тип DATETIME , куда перед сохранением, и выборками, всегда конвертить дату из ЛВЗ в UTC, и обратно?

5) Какие главные минусы против чтобы временную метку хранить просто как число unixtimestamp? То что выборки , когда нужны всякие DATE специфичные функции, потребуют преобразования в тип дату в каждой строке? (это преобразование может не сложное?, ведь datetime и так хранится как число)

Comments

[Adamos]

UTC позволит поднять второй сервер во Владивостоке или в заграничном облаке и не запутаться, например...
А временные зоны нужны только на фронте.
Соответственно, переход из UTC и обратно - между фронтом и бэком (весь бэк в UTC).
В теории.
На практике - если у вас где-то в форме заполняется тупо дата, а сайт работает в 12 часовых поясах, вам придется придумать, как в этих датах, которые в другом часовом поясе будут другими, не создать неконсистентность. Например, принять правило, что даты - по Москве. Или везде оперировать временем с точностью до часа.

[Дмитрий]

В модели пользователя заводим поле shift, в выводе умножаем на 3600 его и прибавляем к utc в timestamp

[szQocks]

5 - никаких минусов нет, можешь задать тип INT и хранить unix и работать с датами - как с числами

Answer 1

[alexalexes]

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

Answer 2

[Артём Дайнов]

Когда я начинал изучение языков программирование, ко мне пристала одна проблема, из-за которой мне говорили, что я полный нуб.
Я время, в базе, хранил как метку в секундах, да и до сих пор так делаю. А если надо в человеко-понятный уровень превратить, так в PHP есть date(), и в js new Date()
А когда хранят в базе что-то подобное 2025-01-31t12:55:43, то это какой-то мрак.
Конечно, такой подход убирает сложность работы с датами, но я люблю, когда дата представлена как 31 янв 12:55, причем год должен появиться только тогда, когда нынешний и в дате сохранения не совпали.
Да, это лишняя обработка на фронте, но ведь красиво же и еще доступней для пользователей.

А теперь к сути вопроса.
1. Сервер должен иметь постоянный часовой пояс. Клиенту отправлять даты именно в этом часовом поясе. Я бы выбрал нулевой пояс. Просто мне проще в голове представлять как отнимать или прибавлять.
2. На клиенте обрабатывать данные и выставлять часовой пояс соответствуя данным из браузера.
3. Если такая настройка есть, чтобы пользователь изменил часовой пояс, то тут должен произойти просто пересчет и всё.
У вас, на клиенте, должен быть объект js, который должен хранить некоторые глобальные настройки аккаунта, которые должны всегда загружаться вместе со страницей.

Comments

[Akina]

А когда хранят в базе что-то подобное 2025-01-31t12:55:43, то это какой-то мрак.

Если в БД дата-время хранится именно в показанной форме, т.е. в поле строкового типа, то и в самом деле создателя такого бреда есть смысл подозревать в наличии альтернативного мышления.

Но если в БД дата-время хранится в поле типа DATETIME / TIMESTAMP, то написанное вами - это строковое представление значения, сделанное вашим кодом (или используемым клиентом), и вам необходимо уделить время понимаю разницы между хранением и отображением.

Я время, в базе, хранил как метку в секундах, да и до сих пор так делаю. А если надо в человеко-понятный уровень превратить, так в PHP есть date(), и в js new Date()

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

Я уж не говорю о том, что вы при таком хранении однозначно теряете встроенные средства СУБД для обработки временнЫх данных, и, как следствие, производительность.

[szQocks]

Akina, если использовать не datetime / timestamp а просто big int, то смещения уже не будет существовать

чисто интересно ты же вроде опытный, вот я работаю постоянно с датами через биг инт, и все даты - временные метки timestamp - как думаешь исходя из твоего опыта - плохой ли это подход ?

просто интересно мнение эксперта который 15+ лет в базами возиться

[Akina]

Я работаю с MySQL и использую исключительно DATETIME, записывая туда значения, приведённые к UTC. Только клиент знает, какая у него на самом деле зона и текущее смещение, и может правильно преобразовывать UTC в локальное время и обратно. К сожалению, иногда при этом на клиенте приходится преобразовывать значение в строковый параметр запроса, ибо всякие фреймворки да коннекторы запросто могут взять и влезть со своим преобразованием...

если использовать не datetime / timestamp а просто big int, то смещения уже не будет существовать

Ага... но опять же - в BIGINT текущее локальное время и обратно преобразует кто? клиент... тот, кто чётко знает свою зону.

Но вот с BIGINT есть проблемы... попробуй прибавить к записанному значению месяц - ой, какой тебя ждёт геморрой! А с DATETIME проблема решается одним вызовом встроенной функции. Или сгруппировать и подсчитать итоги понедельно...

Answer 3

[ThunderCat]

5) Какие главные минусы против чтобы временную метку хранить просто как число unixtimestamp? То что выборки , когда нужны всякие DATE специфичные функции, потребуют преобразования в тип дату в каждой строке? (это преобразование может не сложное?, ведь datetime и так хранится как число)

Как минимум то что у вас дата не хранится как дата. Про то что не будут работать стандартные функции работы с датами типа разницы в год, месяц, неделю и прочие весьма неочевидные преобразования я вообще молчу, чего стоит банальное вычисление количества дней до, например, конца месяца, с учетом того что каждый месяц имеет разную длину, не говоря уже про високосные года, ну и всякие расписания, где работа с минутами/часами без готовых функций тоже так себе удовольствие. Кроме того, таймстамп имеет свои ограничения, например в нем нельзя хранить даты раньше чем 1970 год, то есть пользователи старше 55 лет дату рождения сохранить не смогут. Ну и горизонт планирования до 2038 года, дальше все. Алсо, вы теряете защиту от кривых данных на уровне типа поля, что тоже +1 в копилку встроенных типов.
В целом, таймстампы это именно метки, то есть "тогда-то произошло такое-то событие, относящееся к текущему времени", со своими ограничениями.