2009-12-05 7 views
8

Я собираюсь хранить даты на имени пользователя на моем сайте, но я не знаю, что является наиболее логичным решением.MySQL: сохранить часовой пояс сервера или часовой пояс пользователя?

Первоначально, хотя я использую часовой пояс сервера, а затем для управления им с помощью операций разницы между датой машиниста сервера и датой пользовательской машины, но я также решил изменить его с помощью часового пояса и даты класса php, поэтому:

<?php 
// my server has for example America/New_York timezone 
$user_timezone = "Europe/Rome"; 
date_default_timezone_set ($user_timezone); 
$date = date ('Y-m-d H:i:s'); 
$sql = "UPDATE users SET user_last_modify = '$date', user_timezone = '$user_timezone' WHERE user_id = 'some id' LIMIT 1;"; 
$res = mysql_query ($sql); 
?> 

Мой вопрос: какое наилучшее решение, сохранить часовой пояс сервера или использовать часовой пояс пользователя?
, и если я использую часовой пояс пользователя, должен ли я сохранить имя часового пояса тоже, как в моем примере?

ответ

14

Я бы рекомендовал использовать часовой пояс сервера или UTC, а не хранить разные данные для каждого пользователя. Таким образом, ваша база данных будет полностью согласованной, и вы можете выполнять некоторые операции, такие как сравнения, без необходимости для каждой записи извлекать столбец user_timezone и выполнять преобразование (которое не является полностью бесплатным)

+1

UTC может упростить большинство вещей. Особенно DST-переключатель –

+4

+1, но тем более для UTC по часовому поясу сервера. Что делать, если вы хотите переместить сервер позже или иметь несколько серверов по всему миру? –

+0

благодарит слишком много за помощь, знаете ли вы также о таблице UTC с противопожарными предложениями? поэтому -1100, -1200, -1300 и т. д. – vitto

2

UTC. Это сэкономит вам много часов разочарования.

Местное время пользователя - это вопрос презентации - гораздо проще конвертировать в/из местного времени для данного пользователя, чем отслеживать TZ полей даты каждой записи в базе данных.

Даже при использовании часового пояса сервера может быть заманчивым, правила перехода на летнее время может измениться на самом короткий срок (см: Argentina DST 2009 - правит-принял решение не использовать DST, appx 1 неделю до того, как должно было случиться.) ; в некоторых случаях сам часовой пояс может измениться (см. Time in Indiana). Определение UTC вряд ли подвергнется таким резким изменениям.

(Рассказ о времени сервера и локальном времени: имел сервер на западном побережье США, перевез его на восточное побережье США, приложения использовали серверное время, все ад сломался. С виртуализацией можно легко и быстро перемещаться серверы разные континенты.)

Смежные вопросы