Есть ли ошибка во всех файлах экспорта mysql с меткой времени на не UTC серверах?

Question

Просто пришлось перенести базу данных 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»)

Answer 1

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

Когда mysqldump запрашивает у сервера данные для записи в файл резервной копии, он начинает с отправки:

SET TIME_ZONE='+00:00';

Устанавливает часовой пояс сеанса (соединения) для подключения mysqldump к UTC, в результате чего эти столбцы TIMESTAMP отправляются сервером в UTC и записываются таким образом в файл резервной копии.

В верхней части файла дампа, он также добавляет это:

/*!40103 SET TIME_ZONE='+00:00' */;

/*! ... */ на самом деле не комментарий , хотя он выглядит как один. !40103 сигнализирует любому серверу MySQL версии 4.01.03 или новее выполнить встроенный оператор как обычно - таким образом, установив часовой пояс сеанса в соединении, где восстанавливается дамп, также в формате UTC, чтобы эти временные метки-как-строки хранятся правильно.

Столбцы

DATETIME не выполняют эти преобразования - только TIMESTAMP ... но для столбцов TIMESTAMP на новом сервере не должно быть неправильных значений. Значения в файле дампа указаны в формате UTC, который также является часовым поясом собственного внутреннего формата хранения (вообще не является технически независимым).

---

Обратите внимание также, что больше не рекомендуется устанавливать часовой пояс для сервера в любое время, кроме UTC. Местное время - это вопрос презентации, лучше всего решаемый приложением, а не базой данных. В UTC нет таких двусмысленностей, как в местных часовых поясах, таких как отсутствующий весенний час и дублированный осенний час во многих местных часовых поясах.