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

ЗЫ
структура базы на обе машины выгружалась из одной и той же модели .=== полностью идентична.

Женя_87alex564657498765453,

а как исправлять? создать поле с другим типом? сейчас там тип поля DATETIME

есть таблица users в поле которой users_update записываются периодически данные DATETIME
по истечении суток скрипт удаляет оттуда данные и остаются по умолчанию 0000-00-00 00:00:00

это по базе.

а по пхп, надо чтобы через if-else выводилось из базы но НЕ 0000-00-00 00:00:00, а даты обновления

ну ты смотри сам, мне важно в моей логике было, чтобы это самое время было или больше равно, или меньше последнего_контрольного...я поставил по умолчанию 1971-01-01 00:00:00
и оно было меньше естесвенно чем последнего_контрольного(), а если уже апдейтилось, то больше последнего_контрольного().

у меня правда было таймстемп, но у тебя похожее
документацияThe DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'


как и для юникс-тайм-стемпа, нимимум не равен нулю...

тебе что нужно, если дата есть или нету.
1)разрешить значение НУЛЛ и ставить его вместо нулей.

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

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

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

- проще писать код клиентов этих данных, если везде по коду извесно - в базе ютс.
(просто иногда их достаешь как бинарные данные, ещо какие экзотические финты)

ЗЫ
кслову говоря. файловая система хранит метки времени изменения файлов в ютс времени(гринвич) - поэтому удобно, переставил винчестер в другой комп, он всёравно покажет верную дату изменения файла, даже не зная где винчестер стоял до этого.

ЗЫЗЫ
как тебе поступить с нулевым временем - надо знать конкретику задачи, что это время означает? что означает нулевое значение.

ЗЫЗЫЗЫ
ваще подозреваю что ты пропустил мимо лучший способ организации базы.

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

ДЫК - бери тип время(без даты) и ставь на это поле ON UPDATE CURRENT_TIMESTAMP
и оно само будет обновлять поле при изменении записи в таблице. а ночью везде выставляешь время нулевое.

Женя_87,

:) круто.

а нащот значения по умолчанию нулл

при создании , изменении таблицы каждое поле описываеться по типу

<name> <type> <can_be_null? : NULL | NOT NULL> default <value>

...
`date_up` DATETIME NULL DEFAULT NULL,
...