@grigori Читаем плиз внимательно. тип поля DATETIME, а не TIMESTAMP.
сам datetime вообще ничего не знает ни о каких TZ и ни о TZ приложения, но мускуль при записи проверяет валидность даты исходя из системных TZ/локали где крутится база. При использовании магии в datetime можно вообще запихнуть мусор.
И если приложение работает с несколькими TZ и хочет писать DATETIME (а TZ например отдельно), то TZ системы где крутится база должна быть UTC
и невалидная дата может получиться легко, даже при полностью валидном коде но с будущими датами. Неизвестно как в будущем изменят локаль (свойства TZ) и валидная дата для какой-то локали, может стать невалидной. Это при условии что база крутится на системе с этими локалью/TZ
Все что я написал, я написал не потому что я не понимаю как работает в мускуле эти типы данных, а чтобы обратить внимание что бездумное использование datetime может приводить к интересным глюкам. Но если
@grigori так защищает этот тип данных в мускуле, то мне сташно за кровавый энтерпрайз.
Я здесь в срачи не вступаю пока все не перепроверил и точно не знаю и уверен на 100%. Но весело смотреть как любят читать по диагонали пропуская много из написанного.. А насчет типа datetime это реально головная боль потому что на это я наступал при поддержке абсолютно различных продуктов (и массмаркет и полный самодел). И косяки при переводе времени возникали у 100% продуктов независимо от языка разработки. И баги различные от битой сортировки, что нестрашно, до полностью неработающего продукта в течении часа. Просто вообще никто никогда не задумывается о смене часовых поясов и о переводе времени, все тупо юзают datertime, а не timestamp или тот же int.
