Как работать с несколькими часовыми поясами в приложениях, которые хранят даты и время? - PullRequest
4 голосов
/ 09 июля 2010

Я понимаю, что это немного субъективно, но я надеюсь, что здесь можно найти мозг каждого, как они справляются с несколькими часовыми поясами?Здесь есть множество схожих вопросов и одинаково большое количество принятых ответов.

Как вы поняли это в приложениях, которые вы создали, и какие проблемы вам пришлось решить

Ответы [ 6 ]

13 голосов
/ 09 июля 2010

Вы всегда сохраняете дату / время в одном часовом поясе (9 из 10 по лондонскому времени) и конвертируете их на дисплее в часовой пояс вашего пользователя.Это вопрос уровня приложения, а не БД.

11 голосов
/ 09 июля 2010

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

Единственное, что действительно имеет значение, это то, что вы соответствуете ОДНОМУ И ТОЛЬКО ОДНОМУ ЧАСУ , в зависимости от того, что вы выберете, и что у вас есть ПОДТВЕРЖДАЮТКОНВЕРСИИ ЧАСОВ для случаев, когда вам необходим ПРОСМОТР ВРЕМЕНИ В ЧАСТИ , ОТЛИЧНОЙ ОТ ВАШЕГО И ТОЛЬКО ОДНОГО ЧАСОВ .

Итак:

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

Соответствующие преобразования часов : Это зависит от вашего приложения, но вам нужно спросить и ответить на следующее2 вопроса: какое разрешение мне нужно?Нужно ли мне следить за високосными секундами?После того, как вы ответите, вы сможете выбрать стандартные или более сложные библиотеки.Опять же, вы должны задать эти вопросы.

Просмотр времени : когда кто-то выбирает представление о времени (скажем, по тихоокеанскому времени), просто вызовите соответствующее преобразование часов вСпрос.

Действительно, вот и все.

Что касается библиотек, я использую Python для сценариев, но NAIF Spice Library для разработки миссий и внутренний код для навигации космических аппаратов.Разница между ними заключается просто в разрешении и надежности, учитывая все, что вам нужно учитывать (вращение Земли, относительное замедление, замедление, секунды и т. Д.). Конечно, вы выберете библиотеку, которая соответствует вашим потребностям.

Удачи.

Редактировать:

Я забыл упомянуть: не пытайтесь реализовать свою собственную библиотеку управления временем - используйте готовую библиотеку.Если вы попытаетесь, вы можете быть успешным, но ваш реальный проект умрет, и у вас будет только одна средняя библиотека времени для показа.Может быть, я преувеличиваю, но создание надежной библиотеки даты и времени общего назначения далеко не тривиально, то есть это сам по себе проект.

1 голос
/ 09 июля 2010

Один из проектов, над которыми я работаю, использует SQL Server 2005 и GETUTCDATE() для хранения даты в формате UTC.

0 голосов
/ 09 июля 2010

Вам необходимо сохранить информацию о часовом поясе пользователя и всю информацию о часовом поясе.И всегда сохраняйте время в UTC. И когда вы хотите отобразить эту информацию для конкретного пользователя, просто зайдите в часовой пояс этого пользователя (который хранится для этого пользователя) и добавьте или вычтите это количество времени из времени, сохраненного в UTC, и отобразите этоЭто будет в часовом поясе пользователя, который просматривает информацию.

0 голосов
/ 09 июля 2010

+ 1 для @ kubal5003.

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

Однако существует исключение для отчетов, генерируемых сервером. Поэтому я сохраняю название / идентификатор часового пояса (иногда только смещение / смещение), чтобы найти начало дня. Это может быть для всей системы или для каждого клиента / бренда.

Для веб-приложений я обычно определяю часовой пояс пользователя по умолчанию с помощью геолокации (это редко бывает неправильно, поскольку геоданные сейчас достаточно точны).

0 голосов
/ 09 июля 2010

Я думаю, что новая лучшая практика с sql server 2008 - всегда использовать тип данных datetimeoffset. нормализация дат до UTC также является хорошей практикой; но не всегда возможно или желательно.

Смотрите этот пост в блоге для большего количества мыслей: http://blogs.msdn.com/b/bartd/archive/2009/03/31/the-death-of-datetime.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...