Фильтрация поля где хранится дата в формате timestamp()

[Yoskaldyr]

@grigori дал конкретный пример выше с конкретной датой и временем. и твой пост как как раз типичный пример что ты любишь читать по диагонали
Упрощу дальше некуда
Вставить в DATETIME поле дату 2021-03-28 03:30:00 нельзя будет если на сервере где крутится база будет стоять локаль Украины. Если будет UTC - вставится.

Речь ведь идет только о граничных случаях и когда в коде юзается мульти TZ. И единственный рабочий вариант чтобы база крутилась под UTC. А кто хоть раз подумал об этом, т.е. под какой TZ крутится база написав свой код?

Просто я не могу понять, ты или прикалываешься или ты действительно любитель бездумно использовать DATETIME для всех дат?

P.S. Да можно отдельно в запросе к мускулю указывать таймзону - но вы видели хоть раз код который это использует?

 

[Yoskaldyr]

а в каком-то региональном часовом поясе, потенциально невалиден

именно!

 

[fixxxer]

В принципе, какой-то прям проблемы вообще в этом нет, вопрос корректности приложения.

Иногда мне нужно время именно по конкретному часовому поясу. Допустим, в условиях договора прописано, что услуга действует до такой-то даты до двух часов тридцати минут по нижнезадрищенскому времени. Если хранить время окончания договора в utc, то можно легко попасть, поскольку tzdata сейчас не равно tzdata завтра. А если уж это окажется невалидной датой, отдельно разгребать.

Но это, конечно, очень редкий случай, куда чаще уместно хранить в utc и конвертировать в таймзону клиента на момент выполнения запроса. Где-то в посгресовском faq на эту тему было, tldr: always use timestamptz

 

[Yoskaldyr]

tldr: always use timestamptz

но как мы определились выше - у мускуля свой путь

 

[Yoskaldyr]

Вот честно мне интересно - хоть кто-то хоть раз встречал пхп разработчика который бы задал вопрос при разработке - а какой TZ у системы где крутится база мускуля? Что-то я сомневаюсь что хоть несколько наберется.

 

[grigori]

Я задаю.
У меня в проекте сеть заправок по разным временным зонам, в полночь надо отработать reconciliation - закрытие дня.
Все, кто-то заправлялся или заезжал в McDonalds в полночь, могу вспомнить, что кассы в полночь уходят на "пересменку", которая длится до 15 минут. По факту, кассы выключаются чтобы сбросить историю транзакций на сервер.
Почему так долго - да всем пофиг, вот так просто.
Это наглядный пример работы CAP-теоремы - раз в сутки почти вся розница в мире на 10 минут отказывается от availability.
Вот это закрытие дня в каждом городе делается по местному времени. И ничего, весь мир работает.

 

[Yoskaldyr]

@grigori Тут все просто, работать может. Но не всегда. Вернее даже работать будет почти всегда кроме одного раза в году в течении часа

Потому встречные вопросы:
- какая версия мускуля (старые версии мускуля игнорили по умолчанию эти ошибки, новые работают в стрикт режиме по умолчанию)?
- в какой локали/TZ система где крутится база?
- какие флаги запуска мускуля (потому что строгую проверку валидности времени можно отключить флагами)?

Потому что проверить что не работает очень просто - поставить у системы UTC попробовать записать в datetime мускуля 2021-03-28 03:30:00 - success. Сменить локаль в системе на Украину и снова попробовать записать 2021-03-28 03:30:00 - fail.

В принципе ошибка будет на любой локали системы где есть переход зимнее/летнее время, разве что конкретное время/дата будет отличаться.

 

[weregod]

Вот честно мне интересно - хоть кто-то хоть раз встречал пхп разработчика который бы задал вопрос при разработке - а какой TZ у системы где крутится база мускуля? Что-то я сомневаюсь что хоть несколько наберется.

Примите сочувствие. Все "нормальные пасаны" в конфигах это хранят, и для БД, и для приложения.

 

[AnrDaemon]

Ниоткуда невалидная дата сама не появится. Чтобы записать мусор в datetime должна быть ошибка в приложении.

Любой datetime в будущем, если он не в utc, а в каком-то региональном часовом поясе, потенциально невалиден

Мы же договорились, что с датой работаем в приложении и в базу пишем только UTC.

 

[Yoskaldyr]

Мы же договорились, что с датой работаем в приложении и в базу пишем только UTC.

работать с датой только в приложении не исключает того что сервер где крутится база может быть внезапно не в UTC, а чаще всего будет какое либо локальное TZ.
Из более 1000 серверов которые приходилось тюнить/настраивать только на парочке стояло UTC и то только потому что клиент был из Англии, а сервера расположены там же )) Чаще всего если база и пхп находятся на одном сервере, то в 99% в системе будет стоять TZ приложения

И насчет договорились - это мы договорились, а @grigori локальные дату/время из разных таймзон пишет как есть в datetime

Примите сочувствие. Все "нормальные пасаны" в конфигах это хранят, и для БД, и для приложения.

И сколько таких нормальных пасанов наберется? Да даже докер юзают не меняя локаль, взяли за основу что-то популярное и все, а что там внутри настроено - не важно. И даже если они будут менять TZ у контейнера базы, то какой шанс что они выставят в конфиге контейнера базы UTC, учитывая что приложение работает по Киеву? Я могу пованговать, но с бОльшей вероятностью будет именно Киев, как и у приложения.

 

[AnrDaemon]

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

При чём тут это? Мы никакие операции с датой в БД не делаем вообще, только сравниваем.

 

[Yoskaldyr]

При чём тут это? Мы никакие операции с датой в БД не делаем вообще, только сравниваем.

да базе пофиг на операции с датой. база просто не примет на запись 2021-03-28 03:30:00 если у системы где крутится мускуль таймзона будет стоять Europe/Kiev. Если же будет UTC, то все пройдет без ошибок. Привел же точный пример - попробуйте прежде чем писать

 

[WMix]

@Yoskaldyr дай хоть один пример, когда нужно записать datetime в будущем? позвони в через неделю в 8 утра, заранее подразумевает временную зону клиента, это не тот пример.
остальное, то что по факту записали, это истина - ровно столько и было на сервере. возможны повторения времени при переходе лето зима, но хоть как записывай, при формате h:i:s ты получишь тот же эффект. в чем смысл разделять я не понимаю

 

[Yoskaldyr]

@WMix Насчет будущего это больше высосано из пальца (шанс очень небольшой), но и не я первый насчет этого упомянул. И насчет того что подразумевается TZ, это понятно, но точно так же не я первый упомянул что в DATETIME пишем как есть, а TZ храним отдельно.

Основная проблема это любые даты (прошлые, текущие, будущие) когда время переводят вперед и база крутится под этой локальной TZ. Т.е. чтобы datetime не косячил при вставке база или должна работать под той локальной TZ где нет перевода времени или сразу под UTC. Но во втором случае приложение должно знать что база работает под UTC и не использовать при запросах функции текущего времени.

Я конечно люблю срачи, но отстаивающие повсеместное использование datetime в мускуле, действительно не видят багов использования при мульти TZ приложениях, серьезно? Или это чисто для продолжения срача Или это старая привычка со времен древнего мускуля когда не было строгих проверок на стороне базы и было пофиг что туда писать?

 

[WMix]

если я знаю TZ клиента и сервера, то лично я не вижу проблем.
как показать дату/время это проблема view а не сервера.
если только в сортировке строк во время перехода на зимнее время (один и тот-же час повторяется), но это чисто академическая проблема.

 

[grigori]

@Yoskaldyr я вижу ситуацию так: ты регулярно встречаешь ошибки, которые связаны с обработкой даты-времени, экстраполируешь ситуацию почти на все приложения, написанные на php, и считаешь, что проблему надо решать на уровне субд.

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

В США в разных штатах перевод времени выполняется в разные дни. Есть отдельные города с отдельными временными зонами и уникальной датой перевода времени. Для Штатов достаточно привычно работать с разными временными зонами. Когда в задаче требования работы с разными TZ есть, проблем с периодами времени нет. В проектах для круглосуточного бизнеса вроде заправок учет во времени работает не "почти всегда", а всегда, потому что за ошибку придется выплатить штраф. Если в Европе всем пофиг - это проблема не разработчика.

Второй ошибочный тезис - насчет невалидного значения в datetime. Сервер может работать в UTC, клиент может записать в невалидное значение, но это ничем не отличается от пустого пароля в varchar. За корректность данных отвечает приложение. Если выставить клиентский time_zone, база подстрахует, но это ничего не меняет.

Третья ошибка в тезисах - что timezone меняются. Это просто бред. В договоре с клиентом всегда указывается город - и не просто так. По этому городу считается время. У меня есть понятие location - заправка, у нее в договоре написана tz. Выставляешь соединению с mysql переменную time_zone, и работаешь.

 

[Yoskaldyr]

@grigori Вот любишь ты передергивать
Ты написал как раз все о чем я писал выше.
В результате все что ты написал свелось к тому, что:
- типа неправильная постановка задачи (хотя ошибка не имеет никакого отношения к постановке задачи)
- база должна работать в UTC (как раз об этом я и писал выше и несколько раз)
- использовать переменную time_zone (внезапно тоже об этом писал выше)

Но по факту это как раз то о чем я писал выше и по факту этого сцуко почти НИКТО и НИКОГДА не делает. Не надо быть д'Артаньяном когда у тебя не получается привести факты. А то единственный аргумент это аппелирование к собственному авторитету.

И еще ты так и не ответил на какой версии мускуля работают твои заправки, какие флаги запуска базы и какие TZ у сервера бд. Потому что если это локальная штатовская tz с переводом времени, одна из последних версий мускуля с флагами запуска близким по умолчанию, то это откровенный звиздеж что все работает без ошибок. Вот чистый, откровенный звиздеж. Потому что не может работать без ошибок по определению. И я НЕ ВЕРЮ что ты в своем коде хоть раз использовал set time_zone в своих мускуль запросах.

P.S. И насчет переменной time_zone - это не поможет когда в пределах одной сессии и в пределах одного запроса надо работать сразу с 2 датами из разных TZ

 

[Yoskaldyr]

как показать дату/время это проблема view а не сервера.

Проблема не в том чтобы показать, а в том чтобы записать.

 

[Yoskaldyr]

И еще ты так и не ответил на какой версии мускуля работают твои заправки, какие флаги запуска базы и какие TZ у сервера бд.

Хотя я наверное знаю ответ - там крутится постгре и юзается timestamptz

 

[AnrDaemon]

Мне казалось, мы тут обсуждаем, как сделать правильно, а не как никто никогда не делает?…