Просто пришлось переместить базу данных sql с одного сервера на другой.
Я понимаю, что поле метки времени в MYSQL хранится как 4-байтовое целое число (независимо от часового пояса) и представляется пользователю в нем текущую настройку часового пояса сервера (сервера mysql) Я прав?
Сейчас Когда в октябре в Европе время меняется с летнего на зимнее время (UTC+2 на UTC+1), время накладывается на один час.
Это имеет смысл и не является проблемой, потому что мы «знаем», что сервер знает разницу, потому что он хранит их в отметке времени unix utc.
Я все еще прав?
Теперь, когда я переместил экспорт моей базы данных из одной базы данных в другую, поле метки времени перемещается не как целое число, а как удобочитаемая строка времени:
просто образец:
(1,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 17:38:16',0,NULL,NULL,NULL,NULL,0,NULL),
(2,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 20:00:00',1,NULL,NULL,NULL,NULL,0,NULL),
(3,'AAAA01',6.00,NULL,NULL,NULL,'2017-07-28 21:39:07',0,NULL,NULL,NULL,NULL,0,NULL),
(4,'AAAA01',5.50,NULL,NULL,NULL,'2017-07-28 21:42:15',0,NULL,NULL,NULL,NULL,0,NULL),
(5,'AAAA01',5.00,NULL,NULL,NULL,'2017-07-29 12:55:48',0,NULL,NULL,NULL,NULL,0,NULL),
Вы можете увидеть это поле:
`received` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
но хранится как удобочитаемое поле.
Как принимающий сервер узнает, находится ли это поле до или после изменения времени (в октябре)
Перевод времени происходит 2 раза в год. Весной он идет вперед на один час, так что путаницы нет, так как разница всего в один час, а осенью он идет назад и «перезаписывает» тот же час.
Преобразование часового пояса
Как сервер Mysql вообще может дать ответ на этот раз, поскольку он представляет собой 2 разных времени:
SELECT CONVERT_TZ('2018-10-28 02:40', 'Европа/Париж', 'UTC')