MySQL UTC_TIMESTAMP () игнорирует текущую настройку @@ time_zone

0

У меня есть два сервера Linux/MySQL, расположенных в Великобритании, текущий системный часовой пояс в обоих отчетах BST (GMT + 1), и все же я обнаружил несоответствие в выходе MySQL.

Следующий запрос:

SELECT version(), @@time_zone, @@system_time_zone, NOW(), UTC_TIMESTAMP()

возвращает:

Server A: 5.0.27-community-nt | SYSTEM | GMT | 2010-10-12 12:17:01 | 2010-10-12 11:17:01
Server B: 5.0.45-log | SYSTEM | GMT Daylight Time | 2010-10-12 12:17:51 | 2010-10-12 11:17:51

Итак, сервер A сообщает, что он настроен на GMT. Процесс сервера был запущен 1 марта, когда GMT был в силе, поэтому я ожидал этого. Однако UTC_TIMESTAMP() имеет правильное (но неожиданно) сообщение о том, что UTC составляет 1 час до локального времени.

На сервере B процесс MySQL был запущен в течение лета, поэтому он корректно сообщает GMT Daylight Time и снова корректно сообщает UTC на час раньше.

Мой вопрос: как сервер А получил "правильный" ответ? И будет ли он по-прежнему правильным 31 октября, когда местное время вернется к GMT + 0?

Теги:

1 ответ

1
Лучший ответ

Я думаю, что происходит, когда вы запускаете сервер MySQL, он заполняет переменную @@system_time_zone, но даже когда она изменяется (например, из-за DST), она не отражается в переменной. Однако, несмотря на то, что @@system_time_zone говорит "GMT", когда сервер MySQL оценивает текущую дату, а @@time_zone - это система, он запрашивает у системы дату и DST, что независимо от того, что говорит переменная system_time_zone. Таким образом, в основном единственная "проблема" здесь заключается в том, что переменная system_timezone не изменяется автоматически, даже если изменяется системный часовой пояс.

Поделиться
  • 0
    Спасибо за это. Меня удивляет, насколько полезна переменная @@ system_time_zone, но следующее дает мне достаточно информации: SELECT TIMEDIFF (NOW (), UTC_TIMESTAMP ())

Ещё вопросы

Сообщество Overcoder
Наверх
Меню