요약

  • 원본 RFC 3339에서-00:00은 UTC 시각은 알지만 로컬 오프셋은 모른다는 뜻이었고,Z와+00:00은 UTC를 선호 기준점으로 제시했습니다. RFC 9557은 이후Z에 '로컬 오프셋 미상' 의미를 부여했으며,+00:00은 그대로 두었습니다.
  • 정규화 후의 동일성은 증거의 동일성이 아닙니다. 원시 형태, 프로필 버전, 시계 품질, 윤초 표, 캡처 행위, 애플리케이션 결과는 별개의 영수증으로 남아야 합니다.

규칙이 바뀌면 아카이브가 다시 읽힌다

어려운 사례는 명백히 유효하지 않은 날짜가 아닙니다. 어제는 정확히 해석됐던 문자열이 오늘 더 새로운 규칙 아래에서 다시 읽히는 경우입니다. 계산된 시각은 같을 수 있지만 그에 부여되는 출처는 더 이상 같지 않습니다.

RFC 3339의 4.3절은-00:00을 특정 상황에 한정했습니다. UTC 시각은 알지만 현지 시간과의 오프셋은 모르는 상황입니다. 반대로Z나+00:00은 UTC가 선호되는 기준점임을 나타냈습니다. 두 형태는 같은 초를 가리키면서도 그 기원에 관한 서로 다른 정보를 전달할 수 있었습니다.

이 선택은 전자우편에서 비롯됐습니다. RFC 2822, 그리고 RFC 5322는-0000에 '생성 시스템의 현지 시간대에 관한 정보 없이 보편시(UT)로 표현된 날짜'라는 의미를 부여합니다. 메시지는 시간상의 질문에는 답하면서 현지 시간대의 질문은 열어 둡니다.

RFC 9557은 상호 운용성이 낮은 관례를 바로잡았다

영 앞의 음수 부호는 실용적 문제를 낳았습니다. ISO 8601:2000과 이후 버전은 이를 허용하지 않았고, 로컬 오프셋 미상을 표현하려던 구현은 흔히Z를 사용했습니다. RFC 9557은 이에 따라 RFC 3339를 개정했습니다. 이제Z가 이 의미를 담을 수 있습니다.

이 개정은 UTC를 선호 기준점으로 제시하는+00:00에는 손대지 않았습니다. 또한-00:00을 공식적으로 폐기(deprecated)로 선언하지도 않았습니다. 대신 그 자리에Z를 권할 뿐입니다.

조사를 위해서는 두 개의 날짜를 보존해야 합니다. 이벤트의 날짜와 해석 규칙의 날짜, 더 정확히는 적용되는 프로필의 버전입니다. 후자가 없으면 현대 라이브러리가 오래된 토큰에 작성자가 의도하지 않은 의미를 부여할 수 있습니다.

다만 표준만으로는 특정 소프트웨어가 구규칙 또는 신규칙을 따랐다는 사실을 증명하지 못합니다. 그 준수 여부는 버전, 설정, 테스트에 관한 흔적을 요구합니다.

숫자 오프셋은 시간대의 이름이 아니었다

RFC 3339는 오프셋을 '현지 시간 빼기 UTC'로 계산합니다. 이 관계는 표현된 시각을 변환하기에 충분합니다. 하지만 시간대 식별자, 국가, 계절 변경 규칙, 장비의 위치는 드러내지 않습니다.

여러 시간대가 어느 날 같은 오프셋을 공유하다가 이후 갈라질 수 있습니다. RFC 8536은 TZif 형식을 별도로 기술하며, 여기에는 전환점, 로컬 시간 유형, 명칭, 윤초 보정이 담깁니다. 단순한+02:00에는 없는 요소들입니다.

UTC 시각만 보존하는 것은 이벤트를 정렬하는 데는 유용합니다. 그러나 여기서 현지 설정이나 미래의 민간 시간 의도를 추론하는 것은 과잉 해석입니다. 선택된 시간대, 그 데이터베이스의 버전, 해당 날짜에 적용된 규칙 역시 필요합니다.

로컬 오프셋 미상은 플로팅 시간이 아니었다

RFC 3339에서 불확실성은 시각에 있지 않습니다. 시각은 UTC로 알려져 있고, 빠진 것은 현지 시간과의 연결입니다. 문서는 인터넷 교환에서 자격 없는 현지 시간을 거부하는데, 그렇게 하면 다른 곳에서 거의 대부분 잘못 해석되기 때문입니다.

RFC 5545가 좋은 반례입니다. iCalendar의 '플로팅(floating)' 시간은 어떤 시간대에도 속하지 않습니다. 같은 시계 필드가 사용자의 위치에 따라 서로 다른 시각에 해당할 수 있습니다. '어디에 있든 11시' 같은 약속에는 의도된 동작입니다.

두 사례를 하나의timezone_unknown필드로 뭉치면 그 차이가 사라집니다. 첫째는 시각은 알지만 현지 맥락을 모르는 경우입니다. 둘째는 벽시계 표기를 유지하면서 시각 자체를 맥락에 맡기는 경우입니다.

사전식 정렬에는 좁은 계약이 있었다

RFC 3339는 편리한 성질을 추구했습니다. 어떤 조건에서는 문자열의 순서가 시간의 순서가 됩니다. 그 조건은 명시적입니다. 시간대가 동일하고 같은 표기로 작성되며, 소수 자릿수도 같아야 합니다.

Z, 서로 다른 오프셋, 길이가 다른 소수부가 섞인 컬렉션은 이 보장에 들어가지 않습니다. 문법은 소문자t와z도 허용하지만, 소비하는 프로토콜이 대문자를 강제할 수 있습니다. 검증된 정오표(errata)는 일부 문구를 다듬고, 부록의 ISO 문법과 인터넷 프로필을 구분해야 함을 상기시킵니다.

사전식 정렬에 앞서 시스템은 자신의 비교 프로필을 확정해야 합니다. 정규 형태를 도출할 수 있지만, 수신된 원시 형태는 보존해야 합니다. 그렇지 않으면 색인 편의가 증거의 손실로 변합니다.

소수 자릿수는 기록의 정밀도였지 시계의 정확도가 아니었다

RFC 3339는 자주 쓰이지 않는 한 가지 선택만 남깁니다. 초의 소수부입니다. 이는 엄격한 순서 요구나 특이한 정밀도 요구에 쓰입니다. 더 긴 자릿수는 기록의 입도(granularity)를 나타낼 뿐, 시계가 그만큼 정확했다는 증명이 아닙니다.

제대로 동기화되지 않은 센서도 아홉 자리를 찍을 수 있습니다. 추적 가능한 소스는 한 자리도 제공하지 않을 수 있습니다. RFC 5905는 NTP 동기화, 그 계층, 오프셋, 오차를 별도로 다룹니다. 타임스탬프의 문자들에는 그 시계 상태가 들어 있지 않습니다.

따라서 소수 자릿수, 장비의 분해능, 마지막 동기화, 시간 소스, 불확실도, 캡처 경로를 구분해야 합니다. 0을 더해 새로운 관측이 만들어지지는 않습니다.

60초는 외부 달력을 요구했다

문법은 양의 윤초가 삽입되는 달의 마지막에60을 허용합니다. 음의 윤초도 상정하며, 그 경우 최대치는58일 수 있습니다. 파서는 문법만으로 그 보정이 해당 날짜에 예정됐는지 알 수 없습니다.

RFC 8536은 보정과 전환이 버전화된 데이터에 담겨 있음을 보여주고, RFC 5905는 별개의 동기화 상태를 제공합니다. 따라서23:59:60을 받아들이는 것은 해당 날짜를 권위 있는 표와 대조하기 전까지는 문법상의 영수증에 불과합니다.

시간 척도 역시 각자의 경계를 갖습니다. 윤초를 세는 표현과 세지 않는 표현이 있습니다. 그 숫자를 비교하려면 척도와 사용된 변환을 함께 보존해야 합니다.

타임스탬프는 이벤트를 서명하지 않았다

RFC 3339는 기록 방식을 정의할 뿐입니다. 발신자를 인증하지도, 값이 부여된 시점을 인증하지도, 커버하는 바이트를 인증하지도 않습니다. 서명 옆에 놓인 날짜는 서명 밖에 남을 수 있습니다. 수신 시각은 캡처 시각과 다를 수 있습니다. 형식이 온전한 미래 날짜는 잘못된 설정에서 나올 수 있습니다.

내구성 있는 영수증은 원시 문자열, 프로필, 도출된 시각, 오프셋 토큰, 시계 상태, 불확실도, 시간대와 윤초 데이터, 담고 있는 컨테이너, 암호학적 커버리지, 전송 경로, 애플리케이션 결과를 하나로 묶습니다.

RFC 3339의 역사는 이 요구를 선명하게 보여줍니다. 표현의 의미가 진화해도 연표는 안정될 수 있습니다. 둘 중 하나만 남기면, 올바른 초는 남지만 그것을 신뢰해야 하는 이유는 사라집니다.

출처