[백엔드] timestamp의 Z와 +00:00 이야기

Contents

지난 글들을 보면, timestamp에 대한 이야기를 꽤나 한 것 같다.

 

오늘은 UTC에 대해서 이야기 해볼까 한다.

 

UTC는 표현하는 방법이 2가지가 있다. 둘다 표준이다.

 

2025-12-17T01:00:00Z
2025-12-17T01:00:00+00:00

 

하나는 TZ 모양을 가지고 있고, 다른 하나는 +00:00과 같이 timezone을 표시한다.

 

2025-12-17T01:00:00Z

Z의 의미는 Zulu time이라고 해서, UTC를 의미한다. 즉, Z가 붙어있으면, 이 시간은 무조건 UTC 임을 말한다.

이 표현방식은 ISO 8601 방식이다.

 

Zulu time = UTC 이며, UTC를 부르는 군사 항공 항애 분야의 코드명이다.

(그래서 Phonetic Code에서 유래되었다고 한다)

 

 

2025-12-17T01:00:00+00:00

+00:00의 의미는 offset 기반인데, 범용 시간대 오프셋을 표현하는 것이다. UTC가 범용 시간대임므로 UTC는 +00:00일 수 밖에 없다.

이 표현 방식도 ISO 8601 방식이다.

 

python?

TZ도 표준, offset도 표준이라면, 왜 python에서는 datetime 객체를 .isoformat()으로 문자열로 만들었을 때, +00:00로 표현해줄까?

 

당연한 이야기인 것 같지만, datetime 객체는 tzinfo를 기반으로 timezone을 표시하는데, 즉 설정된 timezone에 따라서 offset 변경을 진행한다는 것이다. Z(zulu time)는 무조건 UTC를 말하므로, 설계상 어울리지 않는다.

 

일반적으로 DB에서도 offset기반으로 저장한다.

 

그러다 보니, python에서는 Zulu time형식의 문자열을 datetime 객체로 변환하기 위해서는 Z를 +00:00과 같이 offset으로 변경하는 작업이 필요하다.

 

그러면 왜 외부 API들을 보면 +00:00과 같은 offset 기반이 아니라, Zulu time으로 보내는 것인가?

이 부분은 RFC 3339 표준으로 의거해서 표준을 지키는 경우다.

RFC 3339는 Internet standards track protocol 이라고 정의된다.

 

그래서 REST API / JSON과 같이 외부에 제공되어야 하는 API들은 Zulu time을 사용하는 경우가 많다.

 

 

Zulu Time의 장점

• 날짜/시간을 일관되게 표현
• Z 자체가 오프셋 0을 의미함을 명시적으로 표현
• 문자열 압축(길이 축소)

 

리얼 월드 분석

토스의 API를 확인해보면, 아래와 같이 yyyy-MM-dd'T'HH:mm:ss±hh:mm 포맷을 사용한다. 즉 offset 기반으로 전송해주고 있다.

즉, 표준 권고, 권장 이지만 어느 쪽을 사용할 것인지는 의도에 따라서 다른 것 같다.

 

단적인 예로, 센서 데이터와 같이 특정 기간의 데이터를 대량으로 보내야 하는 경우, offset기반 보다 Zulu time을 사용했을 때, 데이터 1개당 약 5byte가 절약된다.

 

 

 

 

 

 

코멘트. 아마 조만간 다음 글은 timestamp 압축에 대해서 작성할 것 같다.