많은 서비스들에서 날짜 정보를 3일 전
처럼 표기하는 경우가 많다. 대표적으로 현재 이 글을 적고 있는 벨로그도 이러한 표기를 사용한다. 이 몇 일 전 기능을 실제로 구현하려고 하면 어떻게 해야 할까?
하루하루가 지날 때마다 몇 일 전 표기가 바뀌므로 DB에는 실제 날짜가 저장되어야 한다. 몇 일 전으로의 변환은 클라이언트 단에서도, 서버 단에서도 할 수 있다. 하지만, 우리 팀은 해당 변환을 서버 단에서 하기로 결정했다. n초 전과 같은 표기는 서버에서 연산을 하고 클라이언트에게 보내주는 사이에 부정확한 표기가 될 가능성이 있기 때문이다.
오늘은 이 작업을 하는 날이었다. 기존에 Date 객체를 그대로 렌더링하던 방식을 변경하여 현재 시간과의 차이를 계산하여 보여주는 작업을 하기 위해 서버에서 전해 준 값을 확인해보니 숫자 값이 들어오고 있었다.
우리 팀 백엔드는 왜 나에게 숫자 값을 넘겨주었을까?? 🤔🤔🤔
기업에서 시간은 중요한 문제다. 특히 국제적인 서비스를 지원하는 기업에서는 다양한 국가의 사용자들이 몰리기 때문에 나라에 따라 다른 시간 표기로 바꾸지 않으면 어떤 사용자는 엉뚱한 값을 받게 될 지도 모른다. 따라서 정확한 시간을 다루는 것이 중요하다.
오늘까지 시간의 기준을 그리니치 천문대라고 생각하고 있었다. 지금 나이까지도 계속 그렇게 생각하고 있었는데 이번 작업을 위해 찾아보다 보니 자꾸 UTC
라는 단어가 등장했다. 그리고 충격적인 사실을 알게 되었다...
나 때는 교과서에 그리니치 천문대를 기준으로 시간을 센다고 나와있었다. 이를 GMT (Greenwich Mean Time)이라고 부르고 이제는 과거의 세계 표준 시간이 되어버렸다.
나의 상식이 멈춘 사이 등장한 표준 시간대가 UTC (Coordinated Universal Time)이 되었다. 왜 Coordinated Universal Time인데 약자가 UTC가 되었나 했더니 Universal Time Coordinated라고도 표현하는 듯 하다. UTC는 원자 시계를 이용하여 측정한다.
실제 GMT와 UTC 차이를 비교해보면 표준이 바뀐 게 무색하게도 없다. (우리 나라는 그리니치 천문대를 기준으로 9시간이 차이나기 때문에 GMT에서 9시간을 빼면 동일한 시간을 나타냄을 알 수 있다.)
UTC와 GMT의 차이는 초 단위의 미세한 차이이므로 거의 동일한 시간이기는 하나 원자시를 기반으로 한 UTC가 훨씬 정확한 시간을 나타내기 때문에 UTC로 표준이 변경되었다.
백엔드에서 나에게 Date 대신 넘겨주었던 숫자는 UNIX time이다. UNIX time은 1970년 1월 1일 00:00:00 UTC로부터 현재까지 누적된 초
이다. (왜 하필 1970년 1월 1일을 기준으로 하는지는 UNIX의 출시년도가 1971년이기 때문이고, UNIX를 개발한 연구소에서 정의한 개념이기 때문에 이름이 UNIX time이 되었다,)
1970년부터 누적된 초라는 말에 당연히 타입이 정수 범위를 넘을 것이라고 예상하고 타입을 bigInt로 지정하였더니 타입스크립트가 오류를 내뱉었다. 의외로 2038년까지는 32bit 시스템 내에서 시간 표현이 가능하다고 한다. 덕분에 number가 얼마나 큰 수를 커버하는지를 뼈저리게 느낄 수 있었다.
js에서 일반적으로 사용하는 Date의 문제점은 Date만 사용하면 시간대에 대한 고려가 반영되지 않는다는 것이다. 추가적으로 어떤 시간대인지를 명시해야지만 우리가 원하는 정확한 시간을 반영할 수 있다.
UNIX time은 시간을 UTC로 변환해서 UNIX time의 기준 시간과의 시간 차이로 계산한다. 따라서 UTC로 설정되어 있던 시간을 로컬 시간대로 변경하여 작업해야한다는 단점이 있긴 하지만, 별도의 시간대 설정 없이도 정확한 시간을 전달할 수 있다.
잘 읽었습니다. 좋은 정보 감사드립니다.