Я использую пару переменных, которые хранят DateTime.Now как для базы данных, так и для веб-служб. Кто-то спросил, как поведет себя код, если приложение будет развернуто на машинах в разных часовых поясах. Приложение будет манипулировать данными из разных часовых поясов. Как я могу гарантировать, что в результате этого не возникнет никаких проблем?
Как обрабатывать данные с отметками времени, поступающие из разных часовых поясов?
Ответы (3)
Допустим, часть данных поступает из другого часового пояса. Ваша система дает ему отметку времени, которая является текущим временем на вашем компьютере, и сохраняет ее.
Теперь пользователю, находящемуся в другом часовом поясе, нужно посмотреть, когда произошла эта транзакция, и сравнить ее с чем-то в файле журнала в своей системе. Значения времени не будут синхронизироваться, потому что их журнал использует их время, а ваш — ваше.
Типичное решение состоит в том, чтобы хранить время как универсальное время (также называемое временем по Гринвичу). Когда вы получаете запрос из другого часового пояса, вы либо конвертируете дату обратно во время этого часового пояса (чтобы они могли сравнить со своими журналами), либо вы сообщаете им, что вы возвращаете универсальное время, и им придется конвертировать себя (или же переключиться на использование универсального времени, если они еще этого не сделали).
Переход на универсальное время также решит проблему развертывания вашего приложения в другом месте, но более глубокая проблема часового пояса возникает задолго до этого.
Когда вы имеете дело с разными часовыми поясами, часто бывает полезно перевести все на универсальное время. Так уж получилось, что свойство DateTime
дает вам именно это.
Чтобы добавить к правильному ответу NickLarsen...
GETUTCDATE — функция даты в формате UTC в SQL Server 2008.
UtcNow() — функция даты и времени .Net UTC.
Обычно рекомендуется использовать UTC на серверах и преобразовывать часовой пояс пользователя только для отображения (или, по крайней мере, как можно позже).