хочешь сказать что не используешь DEFAULT CURRENT_TIMESTAMP | ON UPDATE CURRENT_TIMESTAMP, NOW() и т.п ? Да ты страшный человек

это твои личные предрассудки и не более, чему доверять: скриптам, или субд.

это не так, хранится она в INT.

неа не использую, зачем?

Я прагматичный человек. И разделяю где должны быть логика приложения, а где хранение данных.

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

Но тут да, спор не о чём, тут надо собственный горький опыт.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

что "не рационального" в том чтоб использовать TIMESTAMP? Это наилучший формат хранения абсолютного значения даты и времени.

затем что это и есть рационально, субд сама зафиксирует время добавления/обновления данных, даже если они добавлены не твоим приложением.

Видимо у тебя много горького опыта, поделись
Я вот как то его не имею с TIMESTAMP.

Мой опыт весьма специфичен, ты не поймешь



_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

глупость, нет никакой необходимости это делать на уровне приложения. Пользы от это ноль, а грабли | усложнения гарантированы
такой запрос всегда отработает корректно

UPDATE `table` SET `time` = NOW()

такой, чреват "горьким опытом" (с timestamp)

UPDATE `table` SET `time` = 'date("Y-m-d H:i:s")'

вот как раз тут второй вариант и даёт "горький опыт"

время фиксируется не в зонах, а в абсолюте. Ты вообще знаешь что такое timestamp?

нет никаких проблем, если твоё приложение знает в какой tz работает, оно должно об этом сообщить субд, установкой переменной при соединении, так же как ты устанавливаешь кодировку.

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

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

Если у тебя будет рассинхрон по настройкам даты-время в приложении и СУБД, ты при твоём подходе получишь явные артефакты. При настройке даты-время есть куча способов обосраться, даже в самых очевидных местах.

Помоему, я повторяюсь.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

А если это не твоё приложение, то в чём вопрос? Что от тебя тогда зависит?

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

в том то и дело что читаю

Не "какой то базовой даты" , а строго определённой - "1970-01-01 00:00:00 UTC". Уж это ты обязан знать. Суть её в том, чтоб отвязаться от календарных разночтений, и упростить расчёт временных интервалов. Главные проблемы тут даже не в различии часовых поясов, а в коллизиях временной шкалы, в странах использующих дебильный DST.

Если, если ... а если у тебя с субд работают несколько приложений, на разных хостах и рассинхрон времени между ними? Тогда не будет "артефактов"? На какие часы тогда полагаться? Вопрос риторический, следить за синхронностью системных RTC вопрос администрирования, а не программирования естественно.

Я ждал когда ты расскажешь о реальных граблях при установке time_zone в mysql, но так и не дождался а ведь они есть
Дело в том что работая с часовыми поясами, правильно использовать именно "временные зоны", а не оффсеты и мускул это умеет из коробки, если бы не одно но. Вместо того чтоб использовать системную timezone.db, она требует экспортировать её в свою базу, делать это нужно вручную утилитой mysql_tzinfo_to_sql и естественно следить за её актуальностью тоже вручную. Без этого в time_zone можно прописывать только оффсет. Вот в этом её главный недостаток. В ситуациях когда ты не можешь контролировать субд, на внутреннюю конвертацию в бд лучше не полагаться, timestamp выводить в виде int и форматировать уже на тороне php. Но это вовсе не означает что нужно отказываться от

просто к делу нужно подходить с умом