Различия в осведомленности о часовых поясах между System TZ и DB TZ?

В настоящее время я переношу базу данных с локального хоста MySQL на Aurora в RDS.

Проверка настроек часового пояса в обеих системах с помощью:

SELECT @@system_time_zone, @@global.time_zone, @@session.time_zone, NOW(), UTC_TIMESTAMP();

Локальный MySQL

+--------------------+--------------------+---------------------+---------------------+---------------------+
| @@system_time_zone | @@global.time_zone | @@session.time_zone | NOW()               | UTC_TIMESTAMP()     |
+--------------------+--------------------+---------------------+---------------------+---------------------+
| AEDT               | SYSTEM             | SYSTEM              | 2017-12-07 15:05:29 | 2017-12-07 04:05:29 |
+--------------------+--------------------+---------------------+---------------------+---------------------+

RDS (Аврора)

+--------------------+--------------------+---------------------+---------------------+---------------------+
| @@system_time_zone | @@global.time_zone | @@session.time_zone | NOW()               | UTC_TIMESTAMP()     |
+--------------------+--------------------+---------------------+---------------------+---------------------+
| UTC                | Australia/Sydney   | Australia/Sydney    | 2017-12-07 15:05:29 | 2017-12-07 04:05:29 |
+--------------------+--------------------+---------------------+---------------------+---------------------+

Проблема:

Временные метки после 1 октября (когда наступает летнее время) одинаковы, но отличаются на один час раньше, см. ниже:

Локальный MySQL

+--------+---------------------+---------------------+
| id     | created_at          | updated_at          |
+--------+---------------------+---------------------+
|      1 | 2017-08-21 05:08:02 | 2017-08-21 05:20:01 |
|      2 | 2017-08-21 05:08:02 | 2017-08-21 05:20:01 |
|      3 | 2017-08-21 05:08:02 | 2017-08-21 05:20:01 |
|  30000 | 2017-09-07 00:45:02 | 2017-09-07 01:10:03 |
|  98350 | 2017-09-30 19:15:03 | 2017-09-30 19:40:03 |
|  98357 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
|  98358 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
|  98359 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
| 100361 | 2017-10-01 19:05:03 | 2017-10-01 19:30:03 |
| 100411 | 2017-10-01 19:10:04 | 2017-10-01 19:35:03 |
| 100412 | 2017-10-01 19:10:04 | 2017-10-01 19:35:03 |
| 394449 | 2017-12-07 08:30:03 | 2017-12-07 09:00:04 |
| 394472 | 2017-12-07 08:30:03 | 2017-12-07 09:00:08 |
+--------+---------------------+---------------------+

RDS (Аврора)

+--------+---------------------+---------------------+
| id     | created_at          | updated_at          |
+--------+---------------------+---------------------+
|      1 | 2017-08-21 06:08:02 | 2017-08-21 06:20:01 |
|      2 | 2017-08-21 06:08:02 | 2017-08-21 06:20:01 |
|      3 | 2017-08-21 06:08:02 | 2017-08-21 06:20:01 |
|  30000 | 2017-09-07 01:45:02 | 2017-09-07 02:10:03 |
|  98350 | 2017-09-30 20:15:03 | 2017-09-30 20:40:03 |
|  98357 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
|  98358 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
|  98359 | 2017-10-01 08:00:02 | 2017-10-01 08:25:03 |
| 100361 | 2017-10-01 19:05:03 | 2017-10-01 19:30:03 |
| 100411 | 2017-10-01 19:10:04 | 2017-10-01 19:35:03 |
| 100412 | 2017-10-01 19:10:04 | 2017-10-01 19:35:03 |
| 394449 | 2017-12-07 08:30:03 | 2017-12-07 09:00:04 |
| 394472 | 2017-12-07 08:30:03 | 2017-12-07 09:00:08 |
+--------+---------------------+---------------------+

Вопросы:

  1. Знают ли обе настройки часовой пояс?
  2. Если нет, то чего нет?
  3. Как я могу сказать, что это так? :-)
  4. Afaik MySQL хранит метки времени в формате UTC и прозрачно преобразует их при чтении и записи в зависимости от часового пояса (дополнительную информацию см. в этом SO answer ). Есть ли способ получить необработанное значение поля метки времени без каких-либо преобразований (прозрачных или непрозрачных)?

person kev    schedule 07.12.2017    source источник
comment
Если это голосование не было случайным, то это было самое быстрое, что я когда-либо получал ^^   -  person kev    schedule 07.12.2017