Incorrect datetime value: mysql в чем ошибка?

Question

[psiklop]

На сервере непонятный глюк, хранил в таблицах даты в формате text "YYYY-MM-DD HH:MM:SS
Решил все преобразовать в timestamp

Некоторые таблицы выдают ошибку:

Ошибка запроса:
#1292 - Incorrect datetime value: '2022-03-27 03:04:45' for column 'time' at row 3356971

Все ошибки связаны только с этой датой и около нее '2022-03-27 03:xx:xx'
Такие строки дают ошибку при INSERT и UPDATE и смены типа

Что это такое, на другом сервере с данной датой никаких проблем?

Comments

[Дмитрий]

show variables like '%zone%'; на обоих серверах?

[psiklop]

Дмитрий, разные
system_time_zone MSK
system_time_zone EEST

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

[psiklop]

Ага, а ведь 27 марта на Украине был переход на летнее время
Хм, а что с того не пойму

[psiklop]

Ну допустим это время (час) вообще выпало, его не существует
В этом дело ?

[Дмитрий]

psiklop,

Ну допустим это время (час) вообще выпало, его не существует

да.

[psiklop]

Хм, интересно, а если бы у меня тогда был TIMESTAMP у меня на целый час сайты зависли бы из-за глюка в базе ?
Ведь во всех скриптах дата в mysql так и добавляется строкой возвращаемой функцией date php

[psiklop]

Разве, что я не помню какая зона стояла 27 марта, может я тогда еще не сменил, эх

[psiklop]

Остается надеяться, что php тоже вовремя среагировал

[psiklop]

Что интересно, когда я преобразую text в DATETIME все проходит успешно, если этого времени нет, почему же ?

[Akina]

Что интересно, когда я преобразую text в DATETIME все проходит успешно, если этого времени нет, почему же ?

Потому что тогда текстовый литерал трактуется как GMT, и всё в порядке. А в случае TIMESTAMP производится преобразование с учётом зоны - и операнд либо результат попадает в несуществующий час.

[psiklop]

Akina, интересно, что же будет, если я сменю зону и преобразую в TIMESTAMP, а потом сменю зону назад.

[Akina]

psiklop,
Ты передаёшь литерал - в любом случае текстовый.

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

При записи в поле типа DATETIME литерал интерпретируется как уже GMT, и значение сохраняется без каких-либо изменений. И соответственно при обратном получении тоже никаких преобразований нет, и литерал выходит строго тот, который сохраняли.

[psiklop]

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

Answer 1

[toxa82]

Потому что нет такого времени, в 2022-03-27 03:00:00 время перевели на час вперед и получилось сразу 2022-03-27 04:00:00. Думаю поэтому БД и материться.