Обработка часовых поясов

Question

У меня есть представление о базе данных, которая получает статус некоторых рабочих элементов. Например, он получает дату начала и дату окончания, а затем выполняет некоторую математику на основе GetDate(), чтобы вернуть мне ответ типа «Work Remaining».

Проблема в том, что сервер базы данных находится в Соединенных Штатах, и я сижу в Австралии.

Итак, время здесь 19h33 20 июля, а GetDate() на сервере возвращает 02h33 20-го числа.

Как обращаться с часовыми поясами? Должен ли мой пользовательский профайл иметь поле часового пояса, и я вычитаю или добавляю часы на стороне клиента? Проблема в том, что все нужно манипулировать датами и временем. То есть приложение и любые отчеты.

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

ALTER VIEW [dbo].[vwSprintSummary] AS 
SELECT 
    SprintId, 
    SprintName, 
    MIN(DateValue) AS FirstSprintDate, 
    MAX(DateValue) AS LastSprintDate, 
    SprintEndDate, 
    COUNT(DISTINCT PersonId) AS AssignedPeople, 
    COUNT(DISTINCT ProjectResourceId) AS AssignedRoles, 
    SUM(AssignedProductiveHours * CanBurnDown) AS Capacity, 
    SUM(CASE WHEN CAST(GETDATE() AS DATE) <= DateValue THEN AssignedProductiveHours* CanBurnDown ELSE 0 END) AS RemainingCapacity 
FROM [vwSprintDailyBreakdown] 
GROUP BY SprintName, SprintId, SprintStartDate, SprintEndDate 
GO 

Так или иначе, мне нужно изменить GetDate() к 'DATEADD ... так что я могу получить ответы на правильный часовой пояс?

В этом случае, «исправление» было бы изменить GETDATE() к DATEADD(HOUR, 17, GETDATE())

Запрограммированные, я знаю, но, в сущности, что бы решить проблему.

Невозможно каким-то образом сообщить серверу моей зоне и получить ее, чтобы вернуть даты на основе моего местоположения?

Answer 1

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

В моих собственных проектах я склонен доверять часам веб-сервера, а не часам сервера базы данных, поэтому я никогда не использую GETUTCDATE() на SQL Server, вместо этого я предоставляю все даты и время как параметр SQL, например. запрос на поиск «размещенных сегодня заказов» предоставит свое собственное определение «сегодня» (т. е. путем предоставления минимального и максимального значения даты/времени).