네트워크 워킹 그룹 G. Klyne
Request for Comments: 3339 Clearswift Corporation
분류: 표준 트랙 C. Newman
Sun Microsystems
2002년 7월
인터넷상의 날짜와 시간: 타임스탬프
이 메모의 상태
이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 트랙 프로토콜을
명시하며, 개선을 위한 논의와 제안을 요청한다. 이 프로토콜의
표준화 단계와 상태에 대해서는 "Internet Official Protocol
Standards"(STD 1)의 최신판을 참조하기 바란다. 이 메모의
배포에는 제한이 없다.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
초록
이 문서는 인터넷 프로토콜에서 사용할 날짜 및 시간 형식을 정의하며,
이는 그레고리력을 사용하여 날짜와 시간을 표현하기 위한 ISO 8601
표준의 프로파일이다.
목차
1. 서론 .................................................. 2
2. 정의 .................................................. 3
3. 두 자리 연도 ........................................... 4
4. 현지 시간 .............................................. 4
4.1. 협정 세계시(UTC) .................................... 4
4.2. 현지 오프셋 ......................................... 5
4.3. 알 수 없는 현지 오프셋 규약 ......................... 5
4.4. 한정되지 않은 현지 시간 ............................. 5
5. 날짜 및 시간 형식 ...................................... 6
5.1. 정렬 ................................................ 6
5.2. 사람이 읽기 쉬움 .................................... 6
5.3. 드물게 사용되는 옵션 ................................ 7
5.4. 중복 정보 ........................................... 7
5.5. 단순성 .............................................. 7
5.6. 인터넷 날짜/시간 형식 ............................... 8
5.7. 제한 사항 ........................................... 9
5.8. 예제 ............................................... 10
6. 참고 문헌 ............................................ 10
7. 보안 고려 사항 ...................................... 11
Klyne, et. al. 표준 트랙 [Page 1]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
부록 A. ISO 8601 수집 ABNF ............................... 12
부록 B. 요일 ............................................. 14
부록 C. 윤년 ............................................. 14
부록 D. 윤초 .........................................,... 15
감사의 말 ............................................... 17
저자 주소 ............................................... 17
전체 저작권 고지 ........................................ 18
1. 서론
날짜 및 시간 형식은 인터넷에서 많은 혼란과 상호운용성 문제를
일으킨다. 이 문서는 발생하는 여러 문제를 다루며, 인터넷
프로토콜에서 날짜와 시간을 표현하고 사용할 때 일관성과
상호운용성을 개선하기 위한 권고를 제시한다.
이 문서는 그레고리력을 사용하여 날짜와 시간을 표현하기 위한
ISO 8601 [ISO8601]
표준의 인터넷 프로파일을 포함한다.
날짜 및 시간 값은 인터넷 프로토콜에서 여러 방식으로 나타날 수
있다. 이 문서는 그중 하나의 공통 사용법, 즉 인터넷 프로토콜
이벤트의 타임스탬프에만 초점을 맞춘다. 이 제한된 고려는 다음
결과를 가진다.
o 모든 날짜와 시간은 0000AD와 9999AD 사이의 어딘가에 있는
"현재 시대"에 속한다고 가정한다.
o 표현된 모든 시간은 협정 세계시(UTC)와 명시된 관계(오프셋)를
가진다. (이는 현지 시간과 위치는 알려져 있을 수 있지만,
UTC와의 실제 관계는 정치인이나 관리자의 알 수 없거나 알 수
없는 조치에 의존할 수 있는 일정 관리 애플리케이션의 일부
사용과는 다르다. 뉴욕에서 2005년 3월 23일 17:00에 해당하는
UTC 시간은 일광 절약 시간제에 관한 관리 결정에 따라 달라질
수 있다. 이 명세는 그러한 고려 사항을 명확히 피한다.)
o 타임스탬프는 UTC 도입 이전에 발생한 시간을 표현할 수 있다.
이러한 타임스탬프는 해당 시점에서 이용 가능한 최선의 관행을
사용하여 세계시를 기준으로 표현된다.
o 날짜 및 시간 표현은 시간상의 한 순간을 나타낸다.
기간이나 간격에 대한 설명은 여기서 다루지 않는다.
Klyne, et. al. 표준 트랙 [Page 2]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
2. 정의
이 문서에서 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"OPTIONAL"은 RFC 2119 [RFC2119]에 설명된 대로 해석해야 한다.
UTC Bureau International des Poids et Mesures(BIPM)가
유지 관리하는 협정 세계시.
second 국제단위계에서 시간의 기본 측정 단위. 외부장에
의해 교란되지 않은 바닥 상태의 세슘-133 원자의
초미세 전이에서 흡수되거나 방출되는 마이크로파
빛 9,192,631,770 주기의 지속 시간으로 정의된다.
minute 60초의 시간 구간. 그러나 분 안에서 윤초가 어떻게
표시되는지는 section 5.7 및 Appendix D의 제한 사항도
참조한다.
hour 60분의 시간 구간.
day 24시간의 시간 구간.
leap year 그레고리력에서 366일이 있는 해. 윤년은 그 연도
숫자가 4로 정수 번 나누어지는 해이며, 단 세기년
(즉 100으로 나누어지는 해)인 경우에는 400으로도
정수 번 나누어져야 한다.
ABNF Augmented Backus-Naur Form으로, [ABNF]에 정의된
것처럼 프로토콜이나 언어에서 허용되는 문자열을
표현하는 데 쓰이는 형식이다.
Email Date/Time Format
RFC 2822 [IMAIL-UPDATE]에 정의된 인터넷 메일에서
사용하는 날짜/시간 형식.
Internet Date/Time Format
이 문서의 section 5에 정의된 날짜 형식.
Timestamp 이 용어는 이 문서에서 시간상의 어떤 순간에 대한
모호하지 않은 표현을 가리키는 데 사용된다.
Z 시간에 적용될 때 UTC 오프셋 00:00을 나타내는
접미사. ICAO 음성 알파벳에서 문자 "Z"를 나타내는
"Zulu"로 흔히 읽는다.
Klyne, et. al. 표준 트랙 [Page 3]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
시간 척도에 대한 자세한 내용은 [NTP]의 Appendix E,
[ISO8601]의 Section 3, 그리고 관련 ITU 문서 [ITU-R-
TF]를 참조한다.
3. 두 자리 연도
다음 요구 사항은 두 자리 연도의 모호성 문제를 해결하기 위한
것이다.
o 인터넷 프로토콜은 날짜에서 네 자리 연도를 생성해야 한다.
o 두 자리 연도의 사용은 폐기 권고된다. 두 자리 연도를
수신한 경우, 잘못된 해석이 프로토콜 또는 처리 실패를
일으키지 않을 때에만 수락해야 한다(예: 로깅이나 추적
목적으로만 사용되는 경우).
o 두 자리 연도를 사용하는 프로그램이 1999년 이후의 연도를
세 자리 숫자로 표현할 수 있다. 이는 프로그램이 단순히
연도에서 1900을 빼고 자릿수를 확인하지 않을 때 발생한다.
이러한 깨진 소프트웨어가 생성한 날짜를 견고하게 처리하려는
프로그램은 세 자리 연도에 1900을 더할 수 있다.
o 두 자리 연도를 사용하는 프로그램이 1999년 이후의 연도를
":0", ":1", ... ":9", ";0", ...로 표현할 수 있다. 이는
프로그램이 단순히 연도에서 1900을 빼고 10년 단위를
US-ASCII 문자 0에 더할 때 발생한다. 이러한 깨진 소프트웨어가
생성한 날짜를 견고하게 처리하려는 프로그램은 숫자가 아닌
10년 단위를 감지하고 적절히 해석해야 한다.
두 자리 연도의 문제는 인터넷 프로토콜에서 사용되는 모든 날짜와
시간이 왜 완전히 한정되어야 하는지를 충분히 보여준다.
4. 현지 시간
4.1. 협정 세계시(UTC)
현지 시간대의 일광 절약 규칙은 매우 복잡하고 현지 법률에 따라
예측할 수 없는 시점에 변경될 수 있으므로, 진정한 상호운용성은
협정 세계시(UTC)를 사용함으로써 가장 잘 달성된다. 이 명세는
현지 시간대 규칙을 지원하지 않는다.
Klyne, et. al. 표준 트랙 [Page 4]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
4.2. 현지 오프셋
현지 시간과 UTC 사이의 오프셋은 종종 유용한 정보이다. 예를 들어
전자 메일(RFC2822, [IMAIL-UPDATE])에서 현지 오프셋은 빠른 응답의
가능성을 판단하는 데 유용한 휴리스틱을 제공한다. 알파벳
문자열로 현지 오프셋에 레이블을 붙이려는 시도는 과거에 좋지
않은 상호운용성 결과를 낳았다 [IMAIL],
[HOST-REQ]. 그 결과, RFC2822 [IMAIL-UPDATE]는 숫자
오프셋을 필수로 만들었다.
숫자 오프셋은 "현지 시간에서 UTC를 뺀 값"으로 계산된다. 따라서
UTC의 동등한 시간은 현지 시간에서 오프셋을 빼서 결정할 수
있다. 예를 들어, 18:50:00-04:00은 22:50:00Z와 같은 시간이다.
(이 예는 음수 오프셋이 오프셋의 절댓값을 더해 처리됨을 보여준다.)
NOTE: ISO 8601에 따르면 숫자 오프셋은 UTC와 정수 분 단위로
차이가 나는 시간대만 나타낸다. 그러나 많은 역사적 시간대는
UTC와 정수 분이 아닌 단위로 차이가 난다. 그러한 역사적
타임스탬프를 정확히 표현하려면 애플리케이션은 이를 표현
가능한 시간대로 변환해야 한다.
4.3. 알 수 없는 현지 오프셋 규약
UTC의 시간은 알려져 있지만 현지 시간에 대한 오프셋을 알 수
없는 경우, 이는 "-00:00" 오프셋으로 표현할 수 있다. 이는
지정된 시간에 대해 UTC가 선호되는 기준점임을 암시하는 "Z" 또는
"+00:00" 오프셋과 의미상 다르다. RFC2822
[IMAIL-UPDATE]는 전자 메일에 대해 유사한 규약을 설명한다.
4.4. 한정되지 않은 현지 시간
현재 인터넷에 연결된 여러 장치는 내부 시계를 현지 시간으로
실행하며 UTC를 인식하지 못한다. 인터넷에는 명세를 만들 때
현실을 받아들이는 전통이 있기는 하지만, 이것이 상호운용성을
희생하면서 이루어져서는 안 된다. 한정되지 않은 현지 시간대의
해석은 지구상의 약 23/24 지역에서 실패하므로, 한정되지 않은
현지 시간의 상호운용성 문제는 인터넷에서 받아들일 수 없는
것으로 간주된다. 현지 시간으로 구성되어 있고, 대응하는 UTC
오프셋을 알지 못하며, 다른 인터넷 시스템과의 시간 동기화에
의존하는 시스템은 UTC와의 올바른 동기화를 보장하는 메커니즘을
사용해야 한다. 적합한 메커니즘은 다음과 같다.
o Network Time Protocol [NTP]을 사용하여 UTC 시간을 얻는다.
Klyne, et. al. 표준 트랙 [Page 5]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
o 같은 현지 시간대에 있는 다른 호스트를 인터넷 게이트웨이로
사용한다. 이 호스트는 다른 호스트로 전송되는 한정되지 않은
현지 시간을 수정해야 한다.
o 사용자에게 현지 시간대와 일광 절약 규칙 설정을 입력하도록
요청한다.
5. 날짜 및 시간 형식
이 절은 날짜 및 시간 형식의 바람직한 특성을 논의하고 인터넷
프로토콜에서 사용하기 위한 ISO 8601 프로파일을 정의한다.
5.1. 정렬
날짜와 시간 구성 요소가 덜 정밀한 것에서 더 정밀한 것 순서로
배치되면 유용한 속성이 달성된다. 날짜와 시간의 시간대가 같고
(예: 모두 UTC), 동일한 문자열로 표현되며(예: 모두 "Z" 또는
모두 "+00:00"), 모든 시간이 같은 수의 소수 초 자릿수를 가진다고
가정하면, 날짜 및 시간 문자열은 문자열로 정렬할 수 있고(예: C의
strcmp() 함수 사용), 시간순 시퀀스가 결과로 나온다. 선택적
구두점이 있으면 이 특성을 위반하게 된다.
5.2. 사람이 읽기 쉬움
사람이 읽기 쉬운 형식은 인터넷 프로토콜의 가치 있는 특징임이
입증되었다. 사람이 읽기 쉬운 프로토콜은 텔넷이 테스트
클라이언트로 충분한 경우가 많고 네트워크 분석기가 프로토콜에
대한 지식으로 수정될 필요가 없기 때문에 디버깅 비용을 크게
줄인다. 반면, 사람이 읽기 쉬운 형식은 때때로 상호운용성 문제를
일으킨다. 예를 들어, 날짜 형식 "10/11/1996"은 국가마다 다르게
해석되기 때문에 전 세계 교환에는 전혀 적합하지 않다. 또한
[IMAIL]의 날짜 형식은 사람들이 어떤 텍스트 문자열이든 허용된다고
가정하고 세 글자 약어를 다른 언어로 번역하거나 생성하기 더 쉬운
날짜 형식(예: C 함수 ctime에서 사용하는 형식)으로 대체했을 때
상호운용성 문제를 일으켰다. 이러한 이유로, 사람이 읽기 쉬움과
상호운용성 사이에 균형을 맞추어야 한다.
모든 국가의 관례에 따라 읽을 수 있는 날짜 및 시간 형식은
없으므로, 인터넷 클라이언트는 날짜를 지역에 적합한 표시
형식으로 변환할 준비가 되어 있어야 한다. 여기에는 UTC를 현지
시간으로 변환하는 것이 포함될 수 있다.
Klyne, et. al. 표준 트랙 [Page 6]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
5.3. 드물게 사용되는 옵션
드물게 사용되는 옵션을 포함하는 형식은 상호운용성 문제를 일으킬
가능성이 높다. 이는 드물게 사용되는 옵션이 알파 또는 베타
테스트에서 사용될 가능성이 낮아, 파싱 버그가 발견될 가능성도
낮기 때문이다. 드물게 사용되는 옵션은 가능할 때마다
상호운용성을 위해 필수로 만들거나 생략해야 한다.
아래에 정의된 형식은 드물게 사용되는 옵션 하나만 포함한다.
초의 소수 부분이다. 이는 날짜/시간 스탬프의 엄격한 정렬을
요구하거나 특이한 정밀도 요구 사항을 가진 애플리케이션에서만
사용될 것으로 예상된다.
5.4. 중복 정보
날짜/시간 형식이 중복 정보를 포함하면, 그 중복 정보가 서로
일치하지 않을 가능성이 생긴다. 예를 들어, 날짜/시간 형식에
요일을 포함하면 요일은 틀렸지만 날짜는 맞거나, 그 반대일
가능성이 생긴다. 날짜에서 요일을 계산하는 것은 어렵지 않으므로
(Appendix B 참조), 요일은 날짜/시간 형식에 포함하지 않아야 한다.
5.5. 단순성
ISO 8601 [ISO8601]에 지정된 날짜 및 시간 형식의 전체 집합은 여러
표현과 부분 표현을 제공하려는 시도 때문에 상당히 복잡하다.
Appendix A에는 ISO 8601의 전체 구문을 ABNF로 번역하려는 시도가
포함되어 있다. 인터넷 프로토콜은 요구 사항이 다소 다르며,
단순성은 중요한 특성임이 입증되었다. 또한 인터넷 프로토콜은
일반적으로 진정한 상호운용성을 달성하기 위해 데이터의 완전한
명세가 필요하다. 따라서 ISO 8601의 전체 문법은 대부분의 인터넷
프로토콜에 너무 복잡한 것으로 간주된다.
다음 절은 인터넷에서 사용하기 위한 ISO 8601 프로파일을 정의한다.
이는 ISO 8601 확장 형식의 적합한 부분집합이다. 대부분의 필드와
구두점을 필수로 만들어 단순성을 달성한다.
Klyne, et. al. 표준 트랙 [Page 7]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
5.6. 인터넷 날짜/시간 형식
ISO 8601 [ISO8601] 날짜의 다음 프로파일은 인터넷의 새 프로토콜에서
사용해야 한다. 이는 [ABNF]에 정의된 구문 설명 표기법을 사용하여
지정된다.
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
NOTE: [ABNF] 및 ISO8601에 따르면, 이 구문의 "T"와 "Z" 문자는
각각 소문자 "t" 또는 "z"로도 쓸 수 있다.
이 날짜/시간 형식은 대문자 'A'-'Z'와 소문자 'a'-'z'를
구분하는 일부 환경이나 컨텍스트(예: XML)에서 사용될 수 있다.
이러한 환경에서 이 형식을 사용하는 명세는 날짜/시간 구문에
사용되는 문자 'T'와 'Z'가 항상 대문자여야 한다고 날짜/시간
구문을 추가로 제한할 수 있다. 이 형식을 생성하는
애플리케이션은 대문자를 사용해야 한다.
NOTE: ISO 8601은 날짜와 시간이 "T"로 구분된다고 정의한다.
이 구문을 사용하는 애플리케이션은 가독성을 위해 full-date와
full-time을 (예를 들어) 공백 문자로 구분하도록 지정할 수 있다.
Klyne, et. al. 표준 트랙 [Page 8]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
5.7. 제한 사항
문법 요소 date-mday는 현재 월 내의 일 번호를 나타낸다. 최댓값은
월과 연도에 따라 다음과 같이 달라진다.
월 번호 월/연도 date-mday의 최댓값
------------ ---------- --------------------------
01 1월 31
02 2월, 평년 28
02 2월, 윤년 29
03 3월 31
04 4월 30
05 5월 31
06 6월 30
07 7월 31
08 8월 31
09 9월 30
10 10월 31
11 11월 30
12 12월 31
Appendix C에는 어떤 연도가 윤년인지 판정하는 샘플 C 코드가
포함되어 있다.
문법 요소 time-second는 윤초가 발생하는 달의 끝에서 값 "60"을
가질 수 있다. 현재까지는 6월(XXXX-06-30T23:59:60Z) 또는
12월(XXXX-12-31T23:59:60Z)이다. 윤초 표는 Appendix D를 참조한다.
윤초가 빼질 수도 있으며, 그때 time-second의 최댓값은 "58"이다.
그 외 모든 때의 time-second 최댓값은 "59"이다. 또한 "Z" 이외의
시간대에서는 윤초 지점이 시간대 오프셋만큼 이동한다(따라서
전 세계에서 같은 순간에 발생한다).
윤초는 먼 미래까지 예측할 수 없다. International Earth Rotation
Service는 몇 주 전에 윤초를 발표하는 공지 [IERS]를 게시한다.
애플리케이션은 윤초가 발표된 뒤에야 삽입된 윤초를 포함하는
타임스탬프를 생성해야 한다.
ISO 8601은 시간이 "24"가 되는 것을 허용하지만, 이 ISO 8601
프로파일은 혼란을 줄이기 위해 시간에 대해 "00"에서 "23" 사이의
값만 허용한다.
Klyne, et. al. 표준 트랙 [Page 9]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
5.8. 예제
다음은 인터넷 날짜/시간 형식의 몇 가지 예이다.
1985-04-12T23:20:50.52Z
이는 UTC에서 1985년 4월 12일 23시 이후 20분 50.52초를 나타낸다.
1996-12-19T16:39:57-08:00
이는 UTC에서 -08:00의 오프셋(태평양 표준시)을 가진 1996년
12월 19일 16시 이후 39분 57초를 나타낸다. 이는 UTC에서
1996-12-20T00:39:57Z와 동등하다는 점에 유의한다.
1990-12-31T23:59:60Z
이는 1990년 말에 삽입된 윤초를 나타낸다.
1990-12-31T15:59:60-08:00
이는 UTC보다 8시간 늦은 태평양 표준시에서 같은 윤초를 나타낸다.
1937-01-01T12:00:27.87+00:20
이는 1937년 1월 1일 정오 네덜란드 시간과 같은 시간상의 순간을
나타낸다. 네덜란드의 표준시는 법률상 1909-05-01부터
1937-06-30까지 정확히 UTC보다 19분 32.13초 앞섰다. 이 시간대는
HH:MM 형식을 사용하여 정확히 표현할 수 없으며, 이 타임스탬프는
표현 가능한 가장 가까운 UTC 오프셋을 사용한다.
6. 참고 문헌
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
9, Nov 1886.
[IMAIL] Crocker, D., "Arpa 인터넷 텍스트 메시지 형식 표준",
STD 11, RFC 822, 1982년 8월.
[IMAIL-UPDATE] Resnick, P., "인터넷 메시지 형식", RFC 2822,
2001년 4월.
[ABNF] Crocker, D. and P. Overell, "구문 명세를 위한
증강 BNF: ABNF", RFC 2234, 1997년 11월.
Klyne, et. al. 표준 트랙 [Page 10]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
[ISO8601] "데이터 요소와 교환 형식 -- 정보 교환 --
날짜와 시간의 표현", ISO 8601:1988(E),
International Organization for Standardization,
1988년 6월.
[ISO8601:2000] "데이터 요소와 교환 형식 -- 정보 교환 --
날짜와 시간의 표현", ISO 8601:2000,
International Organization for Standardization,
2000년 12월.
[HOST-REQ] Braden, R., "인터넷 호스트 요구 사항 --
애플리케이션 및 지원", STD 3, RFC 1123, 1989년 10월.
[IERS] International Earth Rotation Service Bulletins,
<http://hpiers.obspm.fr/eop-
pc/products/bulletins.html>.
[NTP] Mills, D, "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
1992년 3월.
[ITU-R-TF] 시간 신호와 주파수 표준 방출에 관한 International
Telecommunication Union 권고.
<http://www.itu.ch/publications/itu-r/iturtf.htm>
[RFC2119] Bradner, S, "RFC에서 요구 수준을 나타내는 데 쓰는
핵심 단어", BCP 14, RFC 2119, 1997년 3월.
7. 보안 고려 사항
사이트의 현지 시간대는 시스템이 덜 감시되고 보안 탐지에 더
취약할 수 있는 시간을 판단하는 데 유용할 수 있으므로, 일부
사이트는 시간을 UTC로만 내보내고자 할 수 있다. 다른 이들은
이를 편집증으로 인한 유용한 기능 손실로 볼 수도 있다.
Klyne, et. al. 표준 트랙 [Page 11]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
Appendix A. ISO 8601 수집 ABNF
이 정보는 ISO 8601의 1988년 버전에 기반한다. 2000년 개정판에는
일부 변경 사항이 있을 수 있다.
ISO 8601은 자신이 정의하는 날짜 및 시간 형식에 대한 형식 문법을
지정하지 않는다. 다음은 ISO 8601로부터 형식 문법을 만들려는
시도이다. 이는 정보 제공용일 뿐이며 오류를 포함할 수 있다.
ISO 8601은 여전히 권위 있는 참조이다.
ISO 8601의 모호성 때문에 일부 해석이 필요했다는 점에 유의한다.
첫째, ISO 8601은 기본 형식과 확장 형식의 혼합이 허용되는지
명확하지 않다. 이 문법은 혼합을 허용한다. ISO 8601은 시간이
24인 것이 분과 초가 0인 경우에만 허용되는지도 명확하지 않다.
여기서는 시간이 24인 것이 모든 컨텍스트에서 허용된다고
가정한다. date-mday에 대한 제한 사항은 section 5.7에 적용된다.
ISO 8601은 일부 상황에서 "T"를 생략할 수 있다고 말한다. 이
문법은 모호성을 피하기 위해 "T"를 요구한다. ISO 8601은 또한
(section 5.3.1.3에서) 소수 부분이 1보다 작으면 "0"이 앞서야
한다고 요구한다. ISO 8601의 Annex B.2는 소수 부분 앞에 "0"이
없는 예를 제시한다. 이 문법은 section 5.3.1.3이 올바르고
Annex B.2가 오류라고 가정한다.
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-subdecade
date-fullyear = date-century date-year
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
date-yday = 3DIGIT ; 001-365, 001-366 based on year
date-week = 2DIGIT ; 01-52, 01-53 based on year
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-fullyear
dateopt-century = "-" / date-century
dateopt-fullyear = "-" / datepart-fullyear
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
Klyne, et. al. 표준 트랙 [Page 12]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
datespec-full = datepart-fullyear date-month ["-"] date-mday
datespec-year = date-century / dateopt-century date-year
datespec-month = "-" dateopt-year date-month [["-"] date-mday]
datespec-mday = "--" dateopt-month date-mday
datespec-week = datepart-wkyear "W"
(date-week / dateopt-week date-wday)
datespec-wday = "---" date-wday
datespec-yday = dateopt-fullyear date-yday
date = datespec-full / datespec-year
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
Time:
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
Durations:
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
Klyne, et. al. 표준 트랙 [Page 13]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
Periods:
period-explicit = iso-date-time "/" iso-date-time
period-start = iso-date-time "/" duration
period-end = duration "/" iso-date-time
period = period-explicit / period-start / period-end
Appendix B. 요일
다음은 Zeller의 합동식 [Zeller]을 느슨하게 기반으로 한 샘플 C
서브루틴으로, 0000-03-01 이후의 날짜에 대해 요일을 얻는 데
사용할 수 있다.
char *day_of_week(int day, int month, int year)
{
int cent;
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
/* adjust months so February is the last one */
month -= 2;
if (month < 1) {
month += 12;
--year;
}
/* split by century */
cent = year / 100;
year %= 100;
return (dayofweek[((26 * month - 2) / 10 + day + year
+ year / 4 + cent / 4 + 5 * cent) % 7]);
}
Appendix C. 윤년
다음은 어떤 연도가 윤년인지 계산하는 샘플 C 서브루틴이다.
/* This returns non-zero if year is a leap year. Must use 4 digit
year.
*/
int leap_year(int year)
{
return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
}
Klyne, et. al. 표준 트랙 [Page 14]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
Appendix D. 윤초
윤초에 대한 정보는 다음에서 찾을 수 있다.
<http://tycho.usno.navy.mil/leapsec.html>. 특히 여기에는 다음과
같이 적혀 있다.
UTC에 윤초를 도입하기로 하는 결정은 International Earth
Rotation Service(IERS)의 책임이다. CCIR Recommendation에
따르면, 첫 번째 선호 시점은 12월과 6월 말이며, 두 번째
선호 시점은 3월과 9월 말이다.
필요할 때 윤초 삽입은 UTC의 하루 끝에 추가 초로 발생하며,
YYYY-MM-DDT23:59:60Z 형식의 타임스탬프로 표현된다. 윤초는 모든
시간대에서 동시에 발생하므로 시간대 관계는 영향을 받지 않는다.
윤초 시간의 몇 가지 예는 section 5.8을 참조한다.
다음 표는 United States Naval Observatory가 유지 관리하는 표에서
발췌한 것이다. 원본 데이터는 다음 위치에 있다.
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
Klyne, et. al. 표준 트랙 [Page 15]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
이 표는 윤초의 날짜와, 윤초 이후 시간 표준 TAI(윤초로 조정되지
않는 시간 표준)와 UTC 사이의 차이를 보여준다.
UTC 날짜 윤초 이후 TAI - UTC
-------- ---------------------------
1972-06-30 11
1972-12-31 12
1973-12-31 13
1974-12-31 14
1975-12-31 15
1976-12-31 16
1977-12-31 17
1978-12-31 18
1979-12-31 19
1981-06-30 20
1982-06-30 21
1983-06-30 22
1985-06-30 23
1987-12-31 24
1989-12-31 25
1990-12-31 26
1992-06-30 27
1993-06-30 28
1994-06-30 29
1995-12-31 30
1997-06-30 31
1998-12-31 32
Klyne, et. al. 표준 트랙 [Page 16]
RFC 3339 인터넷상의 날짜와 시간: 타임스탬프 2002년 7월
감사의 말
다음 사람들은 이 문서의 이전 형태에 유용한 조언을 제공했다.
Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert,
Robert Elz. 또한 IETF Calendaring/Scheduling 워킹 그룹 메일링
리스트의 참여자와 time zone 메일링 리스트의 참여자에게도 감사를
표한다.
다음 검토자들은 현재 개정판에 유용한 제안을 기여했다. Tom
Harsch, Markus Kuhn, Pete Resnick, Dan Kohn. Paul Eggert는 윤초와
시간대 오프셋의 미묘한 점에 대해 많은 세심한 관찰을 제공했다.
다음 사람들은 이전 초안에 대한 수정과 개선 사항을 지적했다.
Dr John Stockton, Jutta Degener, Joe Abley, Dan Wing.
저자 주소
Chris Newman
Sun Microsystems
1050 Lakes Drive, Suite 250
West Covina, CA 91790 USA
EMail: chris.newman@sun.com
Graham Klyne (편집자, 이 개정판)
Clearswift Corporation
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Klyne, et. al. 표준 트랙 [Page 17]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
감사의 말
RFC Editor 기능에 대한 자금은 현재 Internet Society가 제공한다.
Klyne, et. al. 표준 트랙 [Page 18]
'