1

문제 : 다른 보고서를 생성하기 위해 세계 다른 지역에서 수집 한 많은 양의 시계열 데이터를 쿼리해야합니다.집계 함수를 사용할 때 SQL Server 2014에서 UTC 시간을 현지 시간으로 변환

시계열 테이블은 다음과 같습니다 LoggerId (INT), 날짜 시간 (날짜 시간), 가치 (진수).

datetime은 UTC로 저장되지만 로컬 시간으로 변환해야합니다. 어떤 경우에는 데이터는 언제든지 자신의 보고서에 사용되는 데이터의 시간대를 변경할 수 등

사용자 총 일일/주간/월간 평균과 같은 것들을 얻을 AVG, SUM을 사용하여 집계 할 필요가있다. 예를 들어 사용자 A는 시간대 A에서 로거 1의 데이터를 보려고 결정할 수 있으며 사용자 B는 시간대 B에서 동일한 데이터를 볼 수 있습니다.

지금까지 일광 절약 시간제 덕분에 SQL Server 2014에서 좋은 솔루션을 찾을 수 없었습니다. 극적으로 복잡하게하는. 나는 거기에 내가 무엇을 필요로 할 수있는 새로운 "시간대에서"기능이지만이 어떤 도움을 이해할 수있을 것이다 2014 년

에서 사용할 수 없습니다 SQL 서버 2016 년 알고있다. 다음은


몇 가지 샘플 데이터입니다

LoggerId, DatetimeUTC, 값

1, 2017년 4월 10일 10시 0분 0초, 10

1, 2017년 4월 10일 11시 0분 0초 20

1 2017년 4월 10일 12시 0분 0초 30

1 2017년 4월 10일 13시 0분 0초 40
NZ 시간 (UTC + 12)에서 기록 장치 (1)의 일일 총 도시

쿼리에서 예상 결과 :

LoggerId, DatetimeLocal, 값

1 2017년 4월 10일 30

1, 2017년 4월 11일, 70

+0

, 샘플 데이터 및 예상 출력 게시 – Mansoor

+0

나는 si 약간의 질문을 정리하고 샘플 데이터를 추가했습니다. 감사. – Robert

+0

DST를 제대로 고려해야합니까? –

답변

0

은 DST를 돌려주는 기능 아래에 보라, 당신은 당신의 요구 사항에 따라 수정할 수 있습니다. 당신은 단지 utc datetime과 offset을 전달합니다.

select [dbo].[UDTToLocalTime_Test](getutcdate(),+4) as DateSTim 

오래 전에 내가이 솔루션을 발견하고 희망 그것은 또한 당신을 도울 것입니다 내 시나리오에 잘 작동 : 같은

Create FUNCTION [dbo].[UDTToLocalTime_Test](@UDT AS DATETIME,@offs as SMALLINT) 
RETURNS DATETIME 
AS 
BEGIN 
--==================================================== 
--Set the Timezone Offset (NOT During DST [Daylight Saving Time]) 
--==================================================== 
DECLARE @Offset AS SMALLINT 
SET @Offset = @offs 
--==================================================== 
--Figure out the Offset Datetime 
--==================================================== 
DECLARE @LocalDate AS DATETIME 
SET @LocalDate = DATEADD(hh, @Offset, @UDT) 
--==================================================== 
--Figure out the DST Offset for the UDT Datetime 
--==================================================== 
DECLARE @DaylightSavingOffset AS SMALLINT 
DECLARE @Year as SMALLINT 
DECLARE @DSTStartDate AS DATETIME 
DECLARE @DSTEndDate AS DATETIME 
--Get Year 
SET @Year = YEAR(@LocalDate) 
--Get First Possible DST StartDay 
IF (@Year > 2006) SET @DSTStartDate = CAST(@Year AS CHAR(4)) + '-03-08 02:00:00' 
ELSE SET @DSTStartDate = CAST(@Year AS CHAR(4)) + '-04-01 02:00:00' 
--Get DST StartDate 
WHILE (DATENAME(dw, @DSTStartDate) <> 'sunday') SET @DSTStartDate = DATEADD(day, 1,@DSTStartDate) 
--Get First Possible DST EndDate 
IF (@Year > 2006) SET @DSTEndDate = CAST(@Year AS CHAR(4)) + '-11-01 02:00:00' 
ELSE SET @DSTEndDate = CAST(@Year AS CHAR(4)) + '-10-25 02:00:00' 
--Get DST EndDate 
WHILE (DATENAME(dw, @DSTEndDate) <> 'sunday') SET @DSTEndDate = DATEADD(day,1,@DSTEndDate) 
--Get DaylightSavingOffset 
SET @DaylightSavingOffset = CASE WHEN @LocalDate BETWEEN @DSTStartDate AND @DSTEndDate THEN 1 ELSE 0 END 
--==================================================== 
--Finally add the DST Offset 
--==================================================== 
RETURN DATEADD(hh, @DaylightSavingOffset, @LocalDate) 
END 

그냥 호출해야합니다.

+0

이것은 어떤 종류의 스위치 오버를 기반으로하는 두 세트의 DST 규칙을 구현하는 것으로 보이지만 어떤 countr (y/ies)가 적용되는지 확실하지 않습니다. OP가 여러 시간대와 함께 작동해야하는 것처럼 들리므로,이 경로를 따라 가면 * 모든 국가 *에 대한 규칙을 구현해야합니다. 일부는 미래 보장이 불가능합니다. 또한'DATENAME'이 영어를 반환한다고 가정합니다. 이는 결코 주어지지 않습니다. –

+0

솔루션을 제공해 주셔서 감사합니다. 다른 국가의 시간대 규칙을 자동으로 유지할 수있는 좋은 방법이 있습니까? DST의 한 가지 문제는 항상 바뀌는 것입니다. 내 다른 걱정은 솔루션의 성능입니다. 먼저 벤치 마크를해야합니다. – Robert

1

그런 다음 당신은 단순히 당신을 위해 변환을 수행하기 위해 자신의 .NET의 CLR 스칼라 함수를 작성할 수 있습니다 데이터베이스에 안전하지 않은 CLR 어셈블리를 사용하여 상관 없어. 아래는 Dicko2의 GitHub 프로젝트에 대한 링크입니다.

https://github.com/HostedSolutions/SQLDates

다음 원 드라이브 링크는 위의 CLR 프로젝트에 대한 설치 스크립트 전체를 포함합니다 : 그 공은 당신이 당신의 자신의 CLR 구현하는 방법을 보여줍니다 아래

SQLDatesFunc

을에 예입니다 어셈블리의 사용 :

DECLARE @utcDateTime DATETIME = GETUTCDATE(); 

DECLARE @cstDateTime DATETIME; 
DECLARE @estDateTime DATETIME; 

SET @cstDateTime = [dbo].[ConvertToLocalTimeZone]('Central Standard Time', @utcDateTime); 
SET @estDateTime = [dbo].[ConvertToLocalTimeZone]('Eastern Standard Time', @utcDateTime); 

SELECT @cstDateTime AS CST, @estDateTime AS EST; 
+0

감사합니다. CLR 방식에 대해서도 생각하고있었습니다. 나는 그것을 사용하기 전에 그것을 조사해야 할 필요가있다. 필자의 주된 걱정은 성능과 SQL 그리고 현재 개발 환경에 SQL을 통합하는 방법입니다. – Robert

+0

@ 로버트 걱정하지 않아도 성능면에서 CLR 옵션은 SQL Server에서 만든 모든 사용자 지정 UDF보다 성능이 뛰어날 것이며 DST와 같은 모든 엣지 문제를 처리 할 것입니다. 내 자신의 테스트에 따르면 백만 건의 레코드에서 함수를 호출하면 질의가 약 1 초만 지연됩니다. 통합과 관련하여 필자가 제공 한 스크립트 만 실행하면됩니다 (컴파일이 필요하지 않은 어셈블리를 만들고 설치합니다). –