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
веселит,
Устанавливается как utc, а другой - в UTC + 2, потому что одна машина находится в Лондоне, а другая - в Германии. Я всегда хочу, чтобы часовой пояс был установлен как часовой пояс, потому что это то, что другие люди предложите http://serverfault.com/questions/14685/local-timezones-on-servers-considered-harmful – Thomaschaaf
@Thomas, определенно придерживайтесь сохранения внутреннего представления времени как UTC! Развязка, сохраненные значения из значений предварительной настройки - единственный способ пойти, –
, так почему они говорят, чтобы сохранить его в локальной зоне? – Thomaschaaf