'오후 3시'는 언제인가요?
프론트엔드에서 시간을 다루며 매번 어렴풋이 넘겼던 것들을 세 편에 걸쳐 정리하는 시리즈입니다. 개념 → 언어 → 계약 순으로 내려갑니다.
- '오후 3시'는 언제인가요? — 이 글
- 왜 날짜만 넣었는데 하루 전이 나올까요?
- 이 필드는 UTC여야 할까요?
예약 기능을 만들다 손이 멈춘 적이 있습니다. 사용자가 고른 "7월 30일 오후 3시"를 서버로 보내야 하는데, 그 값이 정확히 무엇인지 저는 설명하지 못했습니다. 제 노트북에서 만든 값은 제 노트북 시계 기준이고 서버는 UTC로 돌고 있습니다. 사용자가 어디에 있을지는 모르고, 예약을 받는 매장은 또 다른 곳에 있습니다.
그동안은
new Date()를 던져놓고 화면에 그럴듯한 숫자가 뜨면 넘어갔습니다. 그런데 그 숫자가 왜 그렇게 나왔는지 설명할 수 없다면 그건 맞은 게 아니라 우연히 안 틀린 것입니다.'오후 3시'라는 값 하나에는 무엇이 빠져 있고, 그 빠진 것을 사람들은 어떻게 표준으로 채워왔을까요?
이 글에서 다루는 내용
이 글은 라이브러리도 API도 아닌 개념을 다룹니다. 시각이 실은 한 종류가 아니라는 것부터 시작해서, Epoch와 UTC라는 기준점이 어떻게 생겼는지, +09:00과 Asia/Seoul이 왜 같은 말이 아닌지, 그리고 세상의 시간 규칙이 왜 코드가 아니라 데이터베이스에 들어 있는지를 봅니다. 처음 보는 개념이 많아도 따라올 수 있도록 실제로 있었던 일들을 예로 들겠습니다.
여기서 잡은 모델이 2편(JavaScript Date의 함정)과 3편(API 계약과 Temporal)의 밑바탕이 됩니다. 사실 시리즈 전체에서 제일 중요한 것은 바로 아래 1장의 구분 하나입니다 — 나머지는 그 구분을 언어와 계약에 대응시키는 일입니다.
- 1. 시각은 한 종류가 아닙니다
- 2. 기준점의 역사 — Epoch와 UTC
- 3. 오프셋은 타임존이 아닙니다
- 4. IANA tzdb — 규칙은 데이터입니다
- 5. 표기의 계보 — ISO 8601부터 RFC 9557까지
- References
1. 시각은 한 종류가 아닙니다
시간을 다루는 코드가 어려운 이유는 계산이 복잡해서가 아닙니다. 서로 다른 세 가지를 같은 이름으로 부르고 있기 때문입니다.
절대시각, 벽시계시각, 기간
사진 한 장을 떠올려 보겠습니다. 사진이 찍힌 그 순간이 있고, 사진 속 벽에 걸린 시계가 가리키던 값이 있습니다. 이 둘은 다른 것입니다. 순간은 지구 어디서 찍었든 하나지만, 그 순간에 벽시계가 가리키는 값은 장소마다 다릅니다.
| 종류 | 무엇인가 | 예 | 타임존이 필요한가 |
|---|---|---|---|
| 절대시각(instant) | 우주에 단 하나뿐인 시점 | 로그인한 순간, 결제가 승인된 순간 | 표시할 때만 필요 |
| 벽시계시각(wall-clock) | 달력과 시계에 적힌 값 | 생일 1994-03-07, 매일 오전 9시 알람 | 애초에 없는 개념 |
| 기간(duration) | 시간의 길이 | 근로시간 8시간, 영상 길이 3분 20초 | 필요 없음 |
절대시각과 벽시계시각을 가르는 질문은 하나입니다. "지구 반대편 사람이 이 값을 볼 때, 다른 숫자로 보여야 자연스러운가?"
- 화상회의 시작 시각은 절대시각입니다. 서울에서 오후 3시일 때 뉴욕에서는 새벽 2시로 보여야 맞습니다. 모두가 같은 순간에 접속해야 하기 때문입니다.
- 생일은 벽시계 날짜입니다. 3월 7일에 태어난 사람은 뉴욕에 가도 3월 7일이 생일입니다. 시차를 적용해서 "당신의 생일은 3월 6일입니다"라고 알려주는 서비스가 있다면 그건 버그입니다.
- 매일 오전 9시 알람도 벽시계시각입니다. 뉴욕으로 출장 가면 뉴욕의 9시에 울려야 합니다. 서울 9시에 해당하는 순간에 울리면 새벽 4시에 깨는 셈입니다.
숨어 있는 네 번째
셋으로 끝나지 않습니다. 하나가 더 있습니다 — 미래의 약속입니다.
"다음 달 15일 오후 3시에 회의"는 절대시각처럼 보이지만 아직 절대시각이 아닙니다. 벽시계시각에 어느 지역의 시계인지를 붙여야 비로소 절대시각으로 환산할 수 있습니다. 그리고 뒤에서 볼 것처럼, 그 환산 규칙은 회의 날짜가 오기 전에 바뀔 수 있습니다.
절대시각 = 시간축 위의 한 점
벽시계시각 = 달력·시계에 적힌 값 (점이 아니라 라벨)
벽시계 + 지역 = 규칙을 적용하면 점이 되는 것
기간 = 두 점 사이의 거리
Date 타입 하나로 이 넷을 다 표현하려다 보니 문제가 생깁니다. Date는 절대시각만 담을 수 있는데, 우리는 거기에 생일도 넣고 마감일도 넣고 예약도 넣습니다. 그리고 화면에 이상한 날짜가 뜰 때마다 시차를 더하고 빼는 코드를 한 줄씩 덧붙입니다. 2편에서 이 이야기를 자세히 하겠습니다.
Recap
시각은 절대시각·벽시계시각·기간이라는 서로 다른 종류로 나뉘고, 여기에 "벽시계시각 + 지역"이라는 미래의 약속이 하나 더 붙습니다. 판별 기준은 "지구 반대편에서 다른 숫자로 보여야 자연스러운가"입니다. 이 구분을 놓친 채 하나의 타입에 전부 담으려는 것이 시간 버그의 거의 모든 출발점입니다.
2. 기준점의 역사 — Epoch와 UTC
절대시각은 결국 어떤 기준점으로부터 얼마나 흘렀는가라는 숫자 하나입니다. 그 기준점과 "1초"의 정의가 어떻게 정해졌는지를 알아두면, 나중에 만나는 이상한 현상들이 덜 이상해집니다.
Unix Epoch
컴퓨터가 쓰는 기준점은 1970년 1월 1일 00:00:00 UTC입니다. 이걸 Unix Epoch라고 부릅니다. 특별한 천문학적 의미는 없고, 1970년대 초 유닉스를 만들던 사람들이 "적당히 가까운 과거"로 잡은 값입니다. 오늘날 Date.now()가 돌려주는 숫자는 이 시점으로부터 지난 밀리초입니다.
Date.now(); // 1785000000000 같은 정수 — Epoch 이후 흐른 밀리초
기준이 하나뿐이라는 점이 중요합니다. Epoch 밀리초에는 타임존이 없습니다. 서울에서 재든 리마에서 재든 같은 순간이면 같은 숫자가 나옵니다. 절대시각을 저장하고 전송할 때 이 숫자가 가장 안전한 이유입니다.
GMT, UT1, TAI, 그리고 UTC
"UTC"는 자주 쓰지만 정확히 무엇인지는 잘 언급되지 않습니다. 짧게 정리하면 이렇습니다.
| 이름 | 무엇을 기준으로 하나 | 성격 |
|---|---|---|
| GMT | 그리니치 천문대의 평균태양시 | 역사적 명칭. 지금은 일상어에 가깝습니다 |
| UT1 | 실제 지구 자전 | 지구가 불규칙하게 돌아서 일정하지 않습니다 |
| TAI | 세슘 원자시계 | 완벽하게 일정하지만 하늘과 어긋납니다 |
| UTC | TAI에 윤초를 끼워 UT1과 맞춘 것 | 원자시의 정확도 + 태양시와의 정합성 |
지구의 자전은 조석 마찰 등으로 아주 조금씩 느려지고, 게다가 그 변화가 불규칙합니다. 그래서 원자시계로만 시간을 세면 몇십 년 뒤에는 정오에 해가 중천에 있지 않게 됩니다. 이 어긋남을 메우려고 필요할 때마다 1초를 끼워 넣는 것이 윤초(leap second)입니다.
윤초는 1972년부터 지금까지 스물일곱 번 삽입됐고, 마지막은 2016년 12월 31일이었습니다. 그리고 2022년 국제도량형총회에서 2035년까지 윤초를 폐지한다는 결의가 통과됐습니다. 컴퓨터 시스템에 주는 부담이 하늘과의 오차보다 크다고 판단한 것입니다.
그런데 Unix 시간은 윤초를 모릅니다
여기서 재미있는 어긋남이 하나 있습니다. POSIX가 정의하는 Unix 시간은 하루를 무조건 86,400초로 셉니다. 윤초가 들어간 날도 86,400초입니다.
즉 Epoch 밀리초는 엄밀히 말하면 "1970년 이후 실제로 흐른 물리적 시간"이 아닙니다. 윤초를 없는 셈 친 UTC 달력을 초로 환산한 값입니다. 윤초가 삽입되는 순간 Unix 시간은 같은 값을 두 번 지나가거나(구현에 따라) 1초 점프합니다.
대형 서비스들은 이 순간의 혼란을 피하려고 leap smear라는 기법을 씁니다. 윤초 1초를 하루 전체에 얇게 펴 발라서, 그날 하루 동안 시계를 아주 조금씩 느리게 가게 만드는 방식입니다. 서버 입장에서는 갑작스러운 점프 없이 부드럽게 넘어갑니다.
프론트엔드에서 윤초를 직접 신경 쓸 일은 거의 없습니다. 다만 "Epoch 밀리초는 물리적 시간의 완벽한 카운터가 아니다" 라는 사실은 알아둘 만합니다. 경과 시간을 정밀하게 재야 한다면 Date.now()가 아니라 단조 증가가 보장되는 performance.now()를 써야 하는 이유이기도 합니다.
Recap
절대시각은 Unix Epoch(1970-01-01 UTC)로부터 흐른 숫자 하나로 표현되고, 이 숫자에는 타임존이 없습니다. UTC는 원자시(TAI)에 윤초를 끼워 지구 자전(UT1)에 맞춘 시간 척도이며, 윤초는 2035년까지 폐지될 예정입니다. 다만 Unix 시간은 하루를 항상 86,400초로 세기 때문에 윤초를 표현하지 않고, 그래서 경과 시간 측정에는 performance.now()가 더 적합합니다.
3. 오프셋은 타임존이 아닙니다
이 시리즈에서 딱 한 문장만 가져가야 한다면 이 절의 제목입니다. 실무에서 만나는 시간 버그의 상당수가 오프셋과 타임존을 같은 것으로 취급해서 생깁니다.
결과값과 규칙
- 오프셋(offset)은
+09:00,-05:00같은 값입니다. UTC로부터 얼마나 떨어져 있는지를 나타내는 그 순간의 결과값입니다. - 타임존(time zone)은
Asia/Seoul,America/New_York같은 식별자입니다. "어느 시점에 어떤 오프셋을 쓰는가"라는 규칙의 집합입니다.
오프셋은 타임존이라는 함수의 출력값입니다. 입력은 두 개입니다 — 지역과 시점.
오프셋 = f(타임존, 시점)
f("Asia/Seoul", 2026-07-30) = +09:00
f("America/New_York", 2026-07-30) = -04:00 ← 서머타임 기간
f("America/New_York", 2026-01-30) = -05:00 ← 표준시 기간
같은 뉴욕인데 계절에 따라 오프셋이 다릅니다. 이것이 일광절약시간제(DST, Daylight Saving Time)입니다. 그래서 America/New_York을 -05:00으로 저장해두면 여름에 한 시간씩 틀립니다.
거꾸로도 성립하지 않습니다. +09:00을 보고 한국이라고 단정할 수 없습니다. 일본도 평양도 +09:00입니다. 오프셋에서 타임존을 복원할 수는 없습니다. 정보가 이미 손실된 상태이기 때문입니다.
DST는 하루를 23시간이나 25시간으로 만듭니다
DST가 실제로 코드를 깨뜨리는 지점은 시차가 아니라 전환의 순간입니다.
America/New_York의 2026년을 예로 들겠습니다.
봄 — 존재하지 않는 시각. 2026년 3월 8일 새벽 2시가 되는 순간 시계가 3시로 뜁니다. 그날 02:30이라는 벽시계시각은 존재하지 않습니다. 그날은 23시간짜리 하루입니다.
가을 — 두 번 존재하는 시각. 2026년 11월 1일 새벽 2시가 되면 시계가 1시로 돌아갑니다. 그날 01:30은 두 번 옵니다. 앞의 것은 -04:00, 뒤의 것은 -05:00입니다. 25시간짜리 하루입니다.
여기서 나오는 결론이 꽤 매섭습니다.
- 벽시계시각에서 절대시각으로의 변환은 함수가 아닙니다. 값이 없을 수도 있고 두 개일 수도 있습니다.
- "하루 뒤"와 "24시간 뒤"는 다른 말입니다. 전환일에는 23시간 뒤 또는 25시간 뒤가 "하루 뒤"입니다.
- "자정"이 없는 날도 있습니다. 실제로 여러 지역이 자정에 전환을 겁니다. 이런 날
00:00을 만들려고 하면 라이브러리가 조용히01:00으로 밀어줍니다.
그리고 규칙은 정치적으로 바뀝니다
타임존 규칙은 물리 법칙이 아니라 각국 정부의 결정입니다. 그리고 생각보다 자주 바뀝니다. 2026년에 실제로 일어난 일들만 봐도 그렇습니다.
- 브리티시컬럼비아(캐나다)가 2026년 3월 9일부터
-07:00으로 고정됐습니다. 봄에 한 번 앞당긴 뒤 다시 되돌리지 않고 그대로 굳혔습니다. - 앨버타(캐나다)가 2026년 6월 18일부터
-06:00으로 고정됐습니다. - 모로코는 2026년 9월 20일부터
+00:00고정으로 바뀔 예정입니다. 이 글을 쓰는 시점에서는 아직 오지 않은 변경인데, 시간 데이터베이스에는 이미 들어와 있습니다.
우리나라도 예외가 아닙니다. 1954년부터 1961년까지 한국 표준시는 +09:00이 아니라 +08:30이었습니다. 서머타임도 여러 차례 있었고 가장 최근은 1987년과 1988년 두 해였습니다 — 서울올림픽 경기를 미국 동부의 황금시간대에 생중계하기 위해서였다는 이야기가 유명합니다.
그래서 무엇을 저장해야 하는가
정리하면 이렇습니다.
| 저장할 값 | 언제 쓰나 | 왜 |
|---|---|---|
| Epoch 밀리초 또는 오프셋 붙은 문자열 | 이미 일어난 일 | 과거의 순간은 변하지 않습니다 |
타임존 식별자(Asia/Seoul) | 앞으로 일어날 약속 | 규칙이 바뀌어도 의도가 보존됩니다 |
오프셋만(+09:00) | 과거 기록의 부가 정보 정도 | 미래에 쓰면 규칙 변경 때 틀립니다 |
미래 시각을 오프셋으로 굳혀 저장하는 것이 왜 위험한지는 3편에서 실제 시나리오로 다루겠습니다.
Recap
오프셋은 특정 시점의 결과값이고 타임존은 시점에 따라 오프셋을 결정하는 규칙입니다. DST 때문에 같은 지역도 계절마다 오프셋이 달라지며, 전환일에는 존재하지 않는 벽시계시각과 두 번 존재하는 벽시계시각이 생깁니다. 게다가 규칙 자체가 정치적 결정으로 계속 바뀌므로, 미래의 약속은 오프셋이 아니라 타임존 식별자로 저장해야 합니다.
4. IANA tzdb — 규칙은 데이터입니다
규칙이 계속 바뀐다면 그 규칙을 코드에 하드코딩할 수는 없습니다. 그래서 세상은 이것을 데이터베이스로 관리합니다.
시간의 위키피디아
IANA Time Zone Database(tzdb, 또는 zoneinfo, Olson database)는 1980년대부터 이어져 온 공개 데이터베이스입니다. 전 세계 각 지역이 언제부터 언제까지 어떤 오프셋을 썼고 앞으로 어떻게 바꿀 예정인지를 담고 있습니다. 과거 데이터도 들어 있어서, 1954년의 서울이 +08:30이었다는 사실도 여기서 나옵니다.
릴리스는 필요할 때마다 나옵니다. 2026년만 해도 세 번 나왔습니다.
| 릴리스 | 날짜 | 주요 내용 |
|---|---|---|
2026a | 2026-03-01 | 몰도바 전환 시각 정정, 윤초 관련 파일 구성 변경 |
2026b | 2026-04-22 | 브리티시컬럼비아 -07:00 영구 고정 |
2026c | 2026-07-08 | 앨버타 -06:00 영구 고정, 모로코 +00:00 예고 반영 |
이 릴리스들은 OS 업데이트, 브라우저 업데이트, 언어 런타임 업데이트, DB 패치를 타고 각자의 속도로 퍼집니다.
그래서 프론트엔드에 왜 중요한가
여기가 핵심입니다. 여러분의 코드는 tzdb를 직접 들고 있지 않습니다. 실행 환경이 들고 있습니다.
사용자 브라우저 ← 브라우저 엔진에 내장된 ICU/CLDR (브라우저 업데이트로 갱신)
Node.js 서버 ← 번들된 ICU (Node 업그레이드로 갱신)
데이터베이스 ← 자체 tz 테이블 (DB 패치로 갱신)
운영체제 ← /usr/share/zoneinfo (OS 업데이트로 갱신)
이 네 곳의 tzdb 버전이 서로 다를 수 있습니다. 그리고 실제로 다릅니다.
- 3년 된 안드로이드 폰의 크롬은 3년 전 규칙으로 시각을 계산합니다.
- 컨테이너 이미지를 오래 안 갱신한 서버도 마찬가지입니다.
- 사용자가 브라우저를 업데이트하지 않으면 방금 바뀐 모로코의 규칙을 모릅니다.
그래서 클라이언트에서 계산한 시각과 서버에서 계산한 시각이 다를 수 있다는 것을 전제로 설계해야 합니다. 결제 마감이나 응모 마감처럼 판정이 걸린 계산은 반드시 서버가 해야 하는 이유가 여기에도 있습니다.
식별자의 규칙과 함정
tzdb 식별자는 대체로 Area/Location 형태입니다. Asia/Seoul, Europe/Paris, America/Argentina/Buenos_Aires처럼요. 지역명은 가장 큰 도시를 쓰는 것이 관례입니다 — 나라 이름을 쓰면 국경이 바뀔 때 곤란해지기 때문입니다.
이름이 바뀌어도 옛 이름은 Link(별칭)로 남습니다. 하위 호환을 지키기 위해서입니다.
Asia/Calcutta → Asia/Kolkata
Europe/Kiev → Europe/Kyiv
Asia/Saigon → Asia/Ho_Chi_Minh
그리고 아주 유명한 함정이 하나 있습니다. Etc/GMT+9는 UTC+09:00이 아니라 UTC−09:00입니다. POSIX가 오프셋 부호를 반대로 쓰는 관습을 물려받았기 때문입니다. Etc/GMT* 계열을 직접 쓸 일은 거의 없지만, 어딘가에서 보게 되면 부호를 한 번 의심해 보시기 바랍니다.
Recap
세상의 시간 규칙은 IANA tzdb라는 공개 데이터베이스로 관리되고, 정치적 결정에 맞춰 연 몇 회씩 갱신됩니다. 이 데이터는 코드가 아니라 실행 환경(브라우저·런타임·OS·DB)에 들어 있고, 각 환경의 버전이 서로 다를 수 있습니다. 따라서 클라이언트와 서버의 시각 계산 결과가 갈라질 수 있다는 것을 전제로 설계해야 하며, 판정이 걸린 계산은 서버에 두어야 합니다.
5. 표기의 계보 — ISO 8601부터 RFC 9557까지
마지막으로, 이 값들을 문자열로 어떻게 적는가입니다. 우리가 매일 보는 2026-07-30T15:00:00+09:00 같은 문자열에도 계보가 있습니다.
ISO 8601 — 방대한 원본
ISO 8601은 날짜와 시각 표기의 국제 표준입니다. 우리가 아는 YYYY-MM-DD 외에도 주 번호 표기(2026-W31-4), 서수일 표기(2026-211), 기간 표기(P1Y2M3DT4H), 구간 표기까지 아우르는 대단히 넓은 규격입니다. 넓은 만큼 구현체가 전부 지원하지 않고, 유료 문서라 링크로 인용하기도 어렵습니다.
RFC 3339 — 인터넷용으로 좁힌 것
그래서 인터넷 프로토콜에서는 RFC 3339를 씁니다. ISO 8601에서 애매한 부분을 걷어내고 하나의 형태로 좁힌 프로파일입니다.
2026-07-30T15:00:00+09:00 오프셋 명시
2026-07-30T06:00:00Z Z = UTC (Zulu)
2026-07-30T06:00:00.123Z 소수 초 허용
REST API의 시각 필드는 대부분 이 형태라고 보면 됩니다. Z는 +00:00과 같은 뜻이고, 항공·군에서 UTC를 "Zulu time"이라 부르던 관습에서 왔습니다.
RFC 3339와 ISO 8601은 완전한 포함 관계가 아니라 거의 겹치는 두 원에 가깝습니다. 예를 들어 RFC 3339는 "오프셋을 모른다"는 뜻으로 -00:00을 허용하지만 ISO 8601은 이를 허용하지 않습니다. 실무에서 부딪힐 일은 드물지만, 두 이름을 혼용해서 쓰는 문서를 볼 때 참고가 됩니다.
RFC 9557 — 빠져 있던 한 조각
RFC 3339에는 한 가지가 담기지 않습니다. 타임존 식별자입니다.
2026-12-25T09:00:00-08:00을 보면 그 순간이 언제인지는 알 수 있지만, 이것이 밴쿠버의 오전 9시인지 로스앤젤레스의 오전 9시인지는 알 수 없습니다. 3절에서 본 대로 오프셋에서 타임존을 복원할 수는 없기 때문입니다. 그리고 미래의 약속에서는 바로 그 정보가 필요합니다.
RFC 9557(2024)은 여기에 대괄호 확장을 붙였습니다. IXDTF, Internet Extended Date/Time Format이라고 부릅니다.
2026-12-25T09:00:00-08:00[America/Vancouver]
2026-07-30T15:00:00+09:00[Asia/Seoul][u-ca=iso8601]
기존 RFC 3339 파서가 대괄호 앞까지만 읽어도 유효한 값이 나오도록 설계된 점이 영리합니다. 그리고 이 형태가 곧 JavaScript Temporal의 직렬화 포맷입니다. 3편에서 다시 만나게 됩니다.
어떤 표기가 무엇을 담는가
| 표기 | 담는 것 | 담지 못하는 것 |
|---|---|---|
1785000000000 | 절대시각 | 지역, 사람이 읽을 형태 |
2026-07-30 | 벽시계 날짜 | 시각, 지역 |
2026-07-30T15:00:00 | 벽시계 일시 | 어느 지역의 시계인지 |
2026-07-30T06:00:00Z | 절대시각 | 원래 어느 지역의 몇 시였는지 |
2026-07-30T15:00:00+09:00 | 절대시각 + 당시 오프셋 | 타임존 식별자 |
…+09:00[Asia/Seoul] | 절대시각 + 오프셋 + 타임존 | — |
PT8H30M | 기간 | 시작점 |
"이 표기가 무엇을 담지 못하는가" 열이 실은 계약 설계의 전부입니다. 담지 못하는 정보가 필요한 순간이 오면 어딘가에서 추측이 시작되고, 추측은 대개 틀립니다.
Recap
ISO 8601이 방대한 원본이고, RFC 3339가 인터넷용으로 좁힌 프로파일이며, RFC 9557이 여기에 타임존 식별자를 붙일 수 있게 확장한 최신 표준입니다. 각 표기는 담는 정보의 범위가 다르므로, 필드에 어떤 표기를 쓸지 고르는 일은 곧 "무엇을 잃어도 되는가"를 고르는 일입니다.
정리
시간을 다루는 사고 모델을 한 장으로 줄이면 이렇습니다.
- 시각은 절대시각·벽시계시각·기간으로 나뉘고, 미래의 약속은 벽시계시각 + 타임존입니다.
- 절대시각은 Epoch로부터의 숫자 하나입니다. 여기엔 타임존이 없습니다.
- 오프셋은 결과값, 타임존은 규칙입니다. 오프셋에서 타임존을 복원할 수 없습니다.
- 규칙은 IANA tzdb에 데이터로 들어 있고, 정치적 결정에 따라 계속 바뀝니다.
- 문자열 표기는 각각 담는 정보가 다릅니다. 무엇을 담지 못하는지가 중요합니다.
다음 편에서는 이 모델을 들고 JavaScript로 내려갑니다. Date 하나가 이 넷을 전부 흉내 내려다 어디서 어떻게 어긋나는지, 그리고 그 어긋남이 왜 30년째 고쳐지지 않았는지를 보겠습니다.
References
표준 문서
- RFC 3339 — Date and Time on the Internet: Timestamps
- RFC 9557 — Date and Time on the Internet: Timestamps with Additional Information
- RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
시간 표준과 tzdb
- IANA — Time Zone Database
- tz database NEWS — 릴리스별 변경 이력
- IANA — Theory and pragmatics of the tz code and data
- BIPM — Resolution 4 of the 27th CGPM (2022), 윤초 폐지 결의
- Google Cloud — Leap smear
배경 읽을거리
