Quiz: Reconciling Clocks That Disagree

로그의 시각이 2026-03-08T06:22:31.118-00:00 이었다. RFC 3339 가 이 오프셋에 준 뜻은?

• UTC 에서 0시간 떨어진 지역, 즉 UTC 를 그대로 쓰는 지역에서 찍혔다는 뜻이다
• 오프셋을 계산할 수 없는 장비가 쓰는 표기로 Z 와 완전히 같은 뜻이다
• UTC 시각은 알지만 그 기록을 남긴 곳의 지역 오프셋은 모른다는 뜻이다
• 시각이 윤초 구간에 걸쳐 있어 초 단위가 확정되지 않았다는 뜻이다

RFC 3339 가 오프셋 없는 지역시각을 인터넷에서 받아들일 수 없다고 못 박은 근거는?

• 해석이 지구의 약 23/24 에서 실패해 어느 지역의 시계인지 밖에서 알 수 없기 때문이다
• 날짜와 시각 사이의 대문자 T 를 생략하는 표기를 ISO 8601 이 허용하지 않기 때문이다
• 초의 소수 자릿수가 규정되지 않아 밀리초와 마이크로초를 구별할 수 없기 때문이다
• 문자열 길이가 줄마다 달라져 고정폭으로 저장하는 색인에 넣을 수 없기 때문이다

두 호스트의 로그가 모두 올바른 지역 오프셋을 달고 있는데, UTC 로 바꿔 세워 보니 원인이 결과보다 뒤에 찍혀 있었다. 가장 그럴듯한 원인은?

• 한쪽이 서머타임 전환 구간에 걸쳐 오프셋을 한 시간 잘못 적었다
• 두 호스트의 지역이 달라 UTC 로 바꾸지 않은 채 문자열로 비교했다
• 수집기가 도착한 순서대로 번호를 다시 매겨 원본의 순서를 잃었다
• 한쪽 호스트의 시계가 시각 동기에 물려 있지 않아 몇 초 앞서 있다

America/New_York 의 2026-03-08 02:30:00 을 오프셋 없는 지역시각으로 받았다. 이 문자열은?

• 대응하는 UTC 순간이 두 개다 — 같은 지역시각이 그날 두 번 온다
• 대응하는 UTC 순간이 없다 — 그 지역시각은 그날 존재하지 않는다
• 대응하는 UTC 순간이 하나뿐이다 — 전환은 자정에만 일어나기 때문이다
• 대응하는 UTC 순간이 세 개다 — 전환 전후와 전환 시점이 모두 유효하다

기준 호스트와의 시각 차이가 어떤 호스트에서 8시간 59분 57초로 나왔다. 이 차이를 어떻게 읽어야 하나?

• 지역 오프셋이 8시간 59분 57초인 지역이므로 그 값을 그대로 오프셋으로 적는다
• 3초는 측정 잡음이므로 버리고 9시간만 그 호스트의 지역 오프셋으로 적는다
• 9시간은 지역 오프셋이고 남는 3초는 그 호스트 시계가 뒤쳐진 양이다
• 9시간은 시계가 앞선 양이고 남는 3초는 네트워크 지연이므로 무시한다

OpenTelemetry 로그 데이터 모델이 Timestamp 와 ObservedTimestamp 를 나눠 둔 이유는?

• 사건이 일어난 원본 시계의 시각과 수집기가 관측한 시각을 따로 담아 대조할 수 있게 하려고
• 같은 값을 두 벌 담아 한쪽이 전송 중에 손상되어도 다른 쪽으로 복구할 수 있게 하려고
• 초 단위와 나노초 단위를 나눠 담아 정밀도가 다른 시스템이 섞여도 되게 하려고
• 지역시각과 UTC 를 나눠 담아 화면에서 지역 시각을 그대로 보여 줄 수 있게 하려고