2009-06-19 2 views
0

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

Когда я делаю это на сервере 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. Как мне обойти это? Должен ли я сделать преобразование из строки в timestamp на стороне PHP?

ответ

1

G'day,

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

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

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

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

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

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

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

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

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

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

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

HTH

веселит,

+0

Устанавливается как utc, а другой - в UTC + 2, потому что одна машина находится в Лондоне, а другая - в Германии. Я всегда хочу, чтобы часовой пояс был установлен как часовой пояс, потому что это то, что другие люди предложите http://serverfault.com/questions/14685/local-timezones-on-servers-considered-harmful – Thomaschaaf

+0

@Thomas, определенно придерживайтесь сохранения внутреннего представления времени как UTC! Развязка, сохраненные значения из значений предварительной настройки - единственный способ пойти, –

+0

, так почему они говорят, чтобы сохранить его в локальной зоне? – Thomaschaaf

0

Вы пробовали это делать?

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

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

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