DST에 대해 알아보자

글로벌 서비스를 운영하면서 DST 관련 이슈가 발생했다.

 

모니터링 그래프에서 데이터가 밀려나오는 이슈였다. 처음에는 월별 그래프로 보면서 데이터를 비교해보았었는데 정말 엉뚱한 데이터 값이 나오고 있었다. 그래서 일별 그래프를 보게되었고 데이터가 하루 씩 밀려나오는 것을 확인할 수 있었다.

 

이슈의 원인은 바로 DST 였다. 

 

DST(Daylight saving time)는 일광 절약 시간제를 의미하고 시계(표준시)를 한 시간 당겨 생활한다. 예를 들면 8시를 9시로 바꾸고, 2시를 3시로 바꾸는 것이다. 예를 들어 평소에 8시에 출근하던 것을 1시간 늘리니까 늘린 후 8시에 출근하면은 원래 시각으로는 7시에 출근한것으로 결론적으론 1시간 일찍 하루를 시작한 효과가 된다.

 

이렇게 보면 이해하기 편하다.

일반	서머타임
00	00
01	02[2]
02	03
03	04
04	05
05	06
06	07
07	08
08	09
09	10
10	11
11	12
12	13
13	14
14	15
15	16
16	17
17	18
18	19
19	20
20	21
21	22
22	23
23	00

 

어떤게 문제였을까?

 

프랑스의 경우 2021년 기준 3월 28일에 Summer Time이 시작되고 10월 31일에 종료가 된다.

따라서 3월 28일에는 하루 총 시간이 23시간, 10월 31일에는 하루 총 시간이 25시간인 셈이다.

 

[Europe/Paris]

2021년 10월 31일 (Summer Time 종료 시점) ~ 2021년 11월 3일

문제가 되는 모니터링 데이터의 Timezone은 'Europe/Paris' 였고, 2021년 10월 31일에 Summer Time이 종료가 된다.

31일에는 02시가 두 번 존재하기 때문에 하루가 총 25시간인데, 청크 단위를 '24 hours'로 잡아서 하루씩 밀린 것이었다.

 

[기존]

timescaledb_experimental.time_bucket_ng('24 hours'::interval, timezone('Europe/Paris', create_dt))

[변경]

timescaledb_experimental.time_bucket_ng('1 day'::interval, timezone('Europe/Paris', create_dt))

위 와 같이 청크 단위를 '1 day'로 변경해주면 해당 이슈는 해결할 수 있다.

 

! 중요

Web에서도 Summer TIme이 종료되는 날짜에는 일별 그래프에 25개의 시간을 어떻게 표현 할 지 고민해 볼 필요가 있다.

따로 고려하지 않으면 02시의 데이터가 2배로 합산 된 값으로 처리되거나, 02시에 해당하는 두 개의 데이터중 하나의 데이터는 유실된 채 클라이언트에게 데이터를 보여줄 수 있기 때문이다.

 

방법으로는 01, 02A, 02B, 03, 04 .... 22, 23 형식으로 표현할 수 도 있다.