백엔드 쪽에서 시간 관련한 처리 해 줄 때 어떻게 넘겨줬으면 좋겠냐고 물어봐서,
"뭐가...? 뭐가 다른데요...?" 하고는 설명 좀 들은 다음에 여기저기서 찾아봤다.
회사는 기본적으로 ISO8601 형식으로 보내고 있는데 또 어떤 부분에는 문서에만 그렇게 쓰여져있고 실질적으로는 유닉스 타임스탬프로 보내는 부분도 있다고 한다.
(다들 얼레벌레 사는 거겠지)
나는 애초에 두 개의 차이를 잘 모르기도 하는데 백엔드 개발자분이 ISO8601 형식이 별로 좋은 형식은 아니라고 해서 물음표살인마는 칭구에게 왜? 어째서? 왜? 왜에? 하고 질문하고 내가 검색해서는 얻어낸 정보들을 간단하게나마 정리.
- 협정세계시(UTC)의 정의
- 1972년 1월 1일 부터 시행된 국제 표준시이며, 1970년 1월 1일 자정을 0 밀리초로 설정하여 기준을 삼아 그 후로 시간의 흐름을 밀리초로 계산한다.- UTC와 GMT(그리니치 평균시)는 혼용되는데 이 둘은 초의 소수점 단위에서만 차이가 나기 때문에 일상에서는 혼용되어 사용하며, 기술적인 표기에서는 UTC가 사용된다.
What is the unix time stamp?
The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the Unix Epoch. It should also be pointed out (thanks to the comments from visitors to this site) that this point in time technically does not change no matter where you are located on the globe. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.
| ISO 8601 | UNIX timestamp | |
|---|---|---|
| 데이터타입 | string | number |
| 형식 | YYYY-MM-DDThh:mm:ss.sssZ | 1702599214 |
| 가독성 | 좋음 | 나쁨 |
| 압축률 | 나쁨 | 좋음 |
간단하게는 이 정도로 정리할 수 있을 것 같은데,
일단 백엔드에서는 프론트에서 보내는 시간을 무조건적으로 신뢰할 수 없다는 것이 기본원칙이기도 한 것 같고 무엇보다 프론트 쪽에서 시간을 보낼 때 타임존을 포함한 UTC를 보내줄 거라는 보장도 되지 않아서 유직스 형식을 사용할 때는 글로벌 서비스일 때 문제가 생길수도 있다고 한다.
다만 회사의 서비스는 철저하게 내수용이고 글로벌 서비스가 될 가능성이 1도 없기 때문에ㅋㅋㅋ
ISO8601 형식이 채택되었던 것 같다.
그리고 무엇보다 우리 회사는 시간 관련한 것을 다룰 때는 무조건 뷰(view)단이 있어서 가독성이 좋은 것이 더 이점을 가졌던 측면도 있는 것 같다.
개발선생님친구의 말에 의하면,
- 타임존이 없어도 유닉스가 더 나은 방식이기는 한 것 같다고 생각
- 그러나 로우데이터를 사람이 봐야 한다면 가독성이 좋지 않아서 별로
- 전부 뷰단이 있다면 유닉스로 가는 게 맞다고 생각
- 물론 어느정도의 오버헤드를 감안해도 human-readable한 데이터가 더 좋다고는 생각
- 데이터 교환 측면에서는 number가 string보다 압축률이 좋으니까 유닉스가 더 우위
- 타임존 관련한 처리에서는 ISO8601이 우위
결론: "나는 생성 타임스탬프(현재 시간으로 찍히는 거)는 유닉스를 선호하지만 사람이 보거나 입력되어야 하는 시간이라면 ISO8601로 함"
결국 개발에는 답이 없고 모든 것이 다 선택이구나...
마치 인생같다...
