Я ищу решение для быстрого и эффективного поиска записей с использованием времени начала и окончания, которые не зависят от текущего системного времени.Я надеюсь, что смогу найти решение, которое не требует, чтобы SQL Server выполнял математику или преобразование в формат данных, хранящихся в таблицах.Учет летнего времени может быть выполнен с использованием второго набора значений, и логика запроса может определить до выполнения, действуют ли американские правила перехода на летнее время.Мое намерение состоит в том, чтобы использовать UTC для текущего времени, чтобы логика могла перемещаться в Azure или другие центры обработки данных и быть независимой от местоположения.
Решения, которые я рассмотрел, но нашли причины, по которым они не отвечают:
- Сохранение целочисленных смещений от UTC с часовым или минутным приращением.Поскольку интервалы времени пересекают 24-часовую отметку, я не могу выполнить операцию между ними, как это: @CURRENT_HOUR BETWEEN 16 И 4.
- Хранение только строк на основе времени (например, 09:00 и 18:00).Эти значения должны быть преобразованы в значение даты и времени для сравнения с другим значением даты и времени.
Используемое текущее решение вычисляет текущее время для каждой записи, используя смещение UTC, и для этого требуется многобольше работы с SQL Server, чем необходимо для этой операции.
Лучшее решение, которое я нашел, это использовать формат DATETIMEOFFSET, задав значения в унифицированном формате 1900-01-01, чтобы записидата независима, и только текущее системное время должно быть соответственно отрегулировано.
ДАННЫЕ
ZIP CITY ST START_OFFSET STOP_OFFSET START_OFFSET_DST STOP_OFFSET_DST
----------------------------------------------------------------------------------------------------------------------
10001 New York NY 1900-01-01 09:00 -5:00 1900-01-01 18:00 -5:00 1900-01-01 09:00 -4:00 1900-01-01 18:00 -4:00
60601 Chicago IL 1900-01-01 09:00 -6:00 1900-01-01 18:00 -6:00 1900-01-01 09:00 -5:00 1900-01-01 18:00 -5:00
80202 Denver CO 1900-01-01 09:00 -7:00 1900-01-01 18:00 -7:00 1900-01-01 09:00 -6:00 1900-01-01 18:00 -6:00
85001 Phoenix AZ 1900-01-01 09:00 -7:00 1900-01-01 18:00 -7:00 1900-01-01 09:00 -7:00 1900-01-01 18:00 -7:00
90001 Los Angeles CA 1900-01-01 09:00 -8:00 1900-01-01 18:00 -8:00 1900-01-01 09:00 -7:00 1900-01-01 18:00 -7:00
QUERY
-- Get the current UTC date/time and adjust it to be 1900-01-01 with the current time and offset
DECLARE @UTC_TIME AS DATETIMEOFFSET = DATEADD(DAY, (DATEDIFF(DAY, SWITCHOFFSET(SYSDATETIMEOFFSET(), '+00:00'), '1900-01-01')) * 1, SWITCHOFFSET(SYSDATETIMEOFFSET(), '+00:00'))
SELECT @UTC_TIME -- EXAMPLE: 1900-01-01 17:00:00.000000 +00:00
SELECT TimeZoneId
FROM dbo.TimeZones
WHERE @UTC_TIME BETWEEN START_OFFSET AND STOP_OFFSET -- Ignoring DST logic for this example
Проблема с этим подходом заключается в том, что UTC катитсяболее 23:59, дата / время в примере будет 1900-01-01 00:00:00 вместо 1900-01-02 00:00:00 и не будет попадать между предполагаемыми значениями диапазона при сравнении,Я надеюсь, что кто-нибудь поможет мне определить лес для деревьев при расчете лучшего смещения или предложит новый подход к структуре данных, который все еще позволит запросу избегать вычислений.
Эта логика должна работать наSQL Server 2008 и я не хотим внедрять CLR для его решения.
Редактировать: Цель этого запроса данных - определить разумное время вызовов для маркетинга B2B в зонах США.Мы в основном используем почтовые индексы с их смещением часовых поясов и возвращаемся к состояниям, если у нас нет данных почтового индекса для потенциального клиента.Наши данные основаны на 99% в США, с несколькими записями на Гуаме, Пуэрто-Рико и т. Д. Если запись дает ложный положительный результат, это не конец света, но мы стараемся ограничить наши маркетинговые телефонные звонки 9A-6P по местному времени.для этих перспектив.
Если раньше я не знал, я ищу способ отслеживать только временной диапазон, а не диапазон дат в этих записях.