> For the complete documentation index, see [llms.txt](https://dyks-organization.gitbook.io/undefined/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dyks-organization.gitbook.io/undefined/timezone.md).

# timezone 로컬-서버 시간대 차이 문제 해결하기

서버에서 개발된 코드를 원격 깃에 올리고, 다시 로컬로 받아서 수정하고 서버에 올리고.. 를 반복하다 보면 env 나 명시된 일경로 등의 누락이나 차이로 인해 신경써줘야 하는 상황들이 생긴다. 

이번에 예측 test-bed 리펙토링 과정에서 그동안 본적 없었던, **시간** 설정으로 인한 문제를 해결했다.

#### 원래 의도한 흐름

데이터분석(예측) 아웃풋을 간편히 확인할 수 있는 데모사이트인데, API 호출을 통해 결과물을 만들어낸다. 이때 유저 입력값을 적절히 가공하여 납득 가능한 그래프 파형을 그려줘야 하는데, API 서버는 request json의 'request time'과 'record time'의 **날짜** 가 동일한지 검증하는 과정을 거친다. 그날의 액티비티를 기준으로 예측을 제공하기 때문

```
1.	사용자가 “07:11” 같은 시간 입력
2.	현재 날짜와 입력 시간을 합쳐 “2024-12-12 07:11” 형식으로 만듦
3.	이 문자열을 datetime 객체로 변환
4.	datetime을 UTC 타임스탬프로 바꿈
```

#### 문제 원인

1. 시간대 차이: 로컬은 한국 시간, 서버는 UTC 사용
2. 시간 조정: 로컬에서 9시간 빼는 로직을 그대로 적용할 때 날짜가 바뀌어버림
3. API 검증 로직: API가 record\_time과 request\_time 의 날짜가 같은지 확인하고 다르면 오류 발생

<figure><img src="https://1445191324-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcG2DvwSWN6Mp5m9B2uyv%2Fuploads%2FkyyBRYbT1GZjemgRNru8%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-24%2010.14.30.png?alt=media&amp;token=6a00a75e-45fd-4175-a6ff-80c232a362d7" alt=""><figcaption></figcaption></figure>

<figure><img src="https://1445191324-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcG2DvwSWN6Mp5m9B2uyv%2Fuploads%2FaQM8eCoy25FUvQiLCUF0%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-12-24%2010.13.57.png?alt=media&amp;token=56387420-28d2-44e5-b0d5-96152e3ebba8" alt=""><figcaption><p>로컬은 KST, 서버는 UTC 사용 중임을 확인했다.</p></figcaption></figure>

#### 해결 방법

1\. UTC 기준 사용: 모든 시간 계산은 UTC로 하고 필요할 때만 로컬 시간으로 바꾼다.

2\. 시간 변환 로직 수정: 로컬 시간 변환 시 서버 시간대 고려해 UTC로 바꾼 후 필요한 시간대로 변환한다.

3\. 테스트 환경 개선: 로컬 테스트 환경을 서버와 같은 시간대로 맞추거나 시간대 변환 테스트 환경을 만든다.

#### Unix timestamp 라는 놈

유닉스 계열 운영체제에서 시간을 표시하는 방법인, 1970년 1월 1일 00:00:00 UTC부터 지난 시간(초)을 밀리세컨 단위까지 표현하는 수이다.

시간대와 관계 없이 UTC 기준으로 동작하기 때문에 컴퓨터 시스템에서 사용하기에 합리적인 측면이 있겠고 모두가 잘 사용하고 있는 시간대이지만 시간이라는 값을 다루는 시스템을 개발 할때 일반 시간대와의 양방향 변환을 꼭 챙겨줘야 한다. Unix to KST 시간 변환 공식을 사용하거나 <https://www.unixtimestamp.com/> 이런 서비스에 넣어보면서 확인하기. 수가 직관적이지도 않아서 두통을 유발함.

`32비트를 사용하므로 당연히 끝이 존재한다. 2038년 문제(Y2K38)로 말해지는 오버플로우 문제도 예정되어 있으며 그때까지 운영될 시스템이라면(?) 이에 대한 예외처리가 필요하다.`

#### 결론

시간대 차이 문제는 분산 시스템에서 자주 발생한다. UTC 기준으로 시간 처리하고 로컬-서버 간 시간대 차이를 고려하는 게 중요하다. 시간 관련 로직 꼼꼼히 검토하고 테스트해서 오류상황은 미리 방지하자.