MySQL и международные даты - PullRequest
Новая
       35

MySQL и международные даты

0 голосов
/ 19 июня 2009

Скажем, у меня есть несколько серверов в разных местах, и я хочу использовать тип даты и времени MySQL для даты поля, и я всегда хочу, чтобы у даты поля была метка времени UTC, поэтому я бы выполнил UTC_TIMESTAMP(), когда добавлю ее в база данных. Теперь скажите, что я хочу, чтобы MySQL вывел UNIX TIMESTAMP для него.

Когда я делаю это на сервере A, я получаю строку «2009-06-17 12:00:00», выполняющую UNIX_TIMESTAMP (STRING), и возвращает номер 1245240000. Который является 2009-06-17 12:00:00 по UTC времени. Теперь я делаю то же самое на сервере B. Я получаю ту же строку назад, так как это строка UTC, но при повторном выполнении UNIX_TIMESTAMP (STRING) я получаю обратно неправильный номер 1245232800, который является временем UTC +2. Как мне обойти это? Должен ли я сделать преобразование из строки в метку времени на стороне PHP?

Ответы [ 2 ]

1 голос
/ 19 июня 2009

G'day,

Спрошу здесь очевидное, вы проверяли дату и время на обеих машинах?

Редактировать: ... и часовой пояс MySQL был одинаковым на обеих машинах?

Обновление: ОК. Проблема в том, что строка метки времени, передаваемая в UNIX_TIMESTAMP, интерпретируется как значение в текущем часовом поясе, которое затем преобразуется обратно в UTC, поэтому, поскольку вы находитесь в MEZ, вычитается два часа, чтобы вернуть его обратно в UTC поэтому 7200 вычитается из вашей временной метки, когда она преобразуется обратно в временную строку Unix.

Следовательно, вариант, который вы видите, когда используете UNIX_TIMESTAMP () для преобразования, возвращается во временную строку эпохи Unix.

Кстати, разве вы не должны использовать тип TIMESTAMP для хранения своих UTC_TIMESTAMPs вместо типа DATETIME?

Обновление: Отсоединение времени презентации от сохраненного времени - это, безусловно, путь. После этого вы можете повторно использовать одни и те же данные по всему миру, и вам нужно будет преобразовывать их в местное время и обратно только тогда, когда вы предоставляете данные пользователю.

Если вы этого не сделаете, то вам придется сохранить временную зону, когда была сделана метка времени, а затем перейти к всевозможным сложным перестановкам необходимости работать, если

  • местный часовой пояс был при переходе на летнее время,
  • В чем разница между часовым поясом в момент сохранения данных и часовым поясом, в котором должны быть представлены данные.

Оставив все это на хранение, когда UTC избавится от этого.

Большинство пользователей не будут так счастливы, если им придется самостоятельно определять местное время на основе возвращенного времени UTC, поэтому системы обычно переводят пользователя в текущее местное время.

Это, конечно, если пользователь хочет, чтобы данные выражались по местному времени, что обычно и происходит. Единственная широко используемая система, которую я могу придумать, вне головы, которая хранит и представляет свои данные в UTC, - это система управления воздушным движением и управления планами полета, которая всегда хранится в UTC (или, точнее, в ZULU) .

НТН

ура

0 голосов
/ 19 июня 2009

Вы пытались это сделать?

Выполните эту инструкцию вместе. 

SET time_zone = 'UTC';
SELECT FROM_UNIXTIME(0), UNIX_TIMESTAMP('2009-06-17 12:00:00'); 
// 1970-01-01 00:00:00        1245240000

Они влияют только на сеанс клиента, но не на конфигурацию сервера.

...