2026년 12월 말 윤초 추가 없음

 (datacenter.iers.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • IERS Bulletin C 72에 따라 2026년 12월 말 UTC에는 윤초가 추가되지 않아, 시간 측정·배포 시스템은 별도 삽입 처리를 준비할 필요가 없음
  • UTC와 TAI의 차이는 2017년 1월 1일 0시 UTC부터 추후 공지까지 UTC-TAI = -37 s로 유지됨
  • 윤초 도입 여부는 UT1-TAI 변화에 따라 결정되며, 가능한 시점은 6월 말 또는 12월 말임
  • Bulletin C는 6개월마다 UTC 시간 단계(time step)를 발표하거나, 다음 가능한 날짜에 시간 단계가 없음을 확인함
  • 2026년 말 UTC 배포에는 새 보정값이 필요 없고, 기존 UTC-TAI = -37 s 관계를 계속 사용하면 됨

IERS Bulletin C 72의 UTC 공지

  • IERS가 2026년 7월 6일 Paris에서 발행한 Bulletin C 72는 2026년 12월 말 윤초를 도입하지 않는다고 밝힘
  • 공지 대상은 시간 측정과 배포를 책임지는 기관임
  • 핵심 값은 다음 두 가지임
    • 2017년 1월 1일 0시 UTC부터 추후 공지까지 UTC-TAI = -37 s
    • 2026년 12월 말에는 UTC에 새로운 시간 단계가 없음

윤초 결정과 공지 주기

  • 윤초는 UT1-TAI의 변화에 따라 UTC에 도입될 수 있음
  • 도입 가능한 시점은 매년 6월 말 또는 12월 말임
  • Bulletin C는 6개월마다 발송됨
    • UTC에 시간 단계가 생기면 이를 발표함
    • 다음 가능한 날짜에 시간 단계가 없으면 이를 확인함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 예측 불가능성은 무엇 때문에 생기는지 궁금함. 지구의 자전과 공전은 소수점 아래 여러 자리까지 알고 있을 것 같았는데, 지질 활동이나 날씨 같은 요인이 자전 속도 차이를 만들어서 예측이 어려운 건가?

    • 짧게 말하면 맞음. 날씨, 지질 활동, 그리고 대수층 고갈·댐 건설 같은 인간의 물 이동, 빙하와 얼음의 융해가 모두 지구의 자전 주기와 자전축에 예측하기 어려운 변화를 줌
      이 모델들은 기억상 낮은 차수의 삼각 다항식이라, 예측 불가능성을 완벽히 모델링하더라도 절단 오차 때문에 아주 높은 정확도로 배포하기 어렵고, 위성 같은 곳에 이미 들어가 있어 임의로 복잡하게 만들 수도 없음
      참고로 윤초는 곧 사라질 예정이고, 2035년에 단계적으로 중단되는 것으로 알고 있음. Russia가 GLONASS 위성을 업데이트할 시간이 필요해서 지연된 걸로 기억함
    • 맞음. 그런 요인들과 더 많은 것들이 있음. 우리의 측정 정밀도는 하루 길이의 해마다 변하는 1차·2차 변화율보다 훨씬 좋음
      https://datacenter.iers.org/singlePlot.php?plotname=Bulletin...가 이와 가장 관련 있는 그래프이고, 수직 점프는 윤초를 나타냄. IERS에는 자전의 다른 차원에 대한 그래프도 있지만 이 그래프가 보기 좋음
    • 마침 마지막 윤초가 언제 들어갔는지 보려고 Wikipedia 문서를 확인했는데, 답도 거기에 있음
      “지구의 자전 속도는 기후 및 지질 사건에 반응해 변하므로 UTC 윤초는 불규칙하게 배치되며 정확히 예측할 수 없다”
      https://en.wikipedia.org/wiki/Leap_second
    • 오히려 반대에 가까움. 지구의 자전은 해마다 몇 초 단위로도 달라질 수 있지만, 수백 년에 걸치면 변동이 대체로 상쇄됨
      그래서 윤초를 더하거나 빼려는 시도는 별로 좋은 생각이 아니라고 봄. 이런 것에 신경 쓰는 건 사실상 우주 기관뿐이고, 그들은 원하는 보정값을 적용하면 되며 모두에게 영향을 줄 필요는 없음
      일반인에게 이 drift가 미치는 현실적 영향은 GPS 정도인데, GPS는 자체 시계와의 오프셋을 이미 전송해서 수신기가 보정할 수 있음. GPS 시계는 UTC와도 TAI와도 다름
    • https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...를 보면 됨

  • 이건 오히려 안티뉴스 아닌가? 오늘날 컴퓨팅 시스템에 문제를 너무 많이 일으켜서 별도 공지가 있을 때까지 윤초 도입을 멈춘 것으로 어렴풋이 기억함
    지금은 37초 차이이고, 누구도 Christmas가 Easter 즈음으로 밀릴까 걱정할 필요는 없음. 이 문제는 다른 많은 문제보다 훨씬 책임 있게 미래 세대에 넘겨도 된다고 봄
    6개월마다 공지가 나오는 건 원래의 국제 조약 문구를 맞추기 위한 절차일 뿐임

    • 아직 그렇게 된 건 아님. 제안일 뿐이고, 공식 중단은 2035년 전까지는 어려울 가능성이 큼
      윤초가 한동안 없었던 이유는 TAI와 UT1 사이의 drift가 느려졌고, 실제로는 아주 천천히 반대 방향으로 움직이고 있기 때문임
    • 공지 기간이 6개월뿐이라는 게 말이 안 된다고 느껴지고, 그게 문제의 원인일 가능성이 큼
      시간이 ±60초 정도 틀려도 아무도 눈치채지 못할 테니, 10년에 한 번쯤 임의의 윤초를 넣고 10년 전에 공지해서 모두가 시스템을 정리할 시간을 주는 편이 더 관리 가능해 보임. 전 세계가 조율해 실행하는 데 6개월은 터무니없이 낙관적임

  • 5살에게 설명하듯 말하면, 이게 UNIX 타임스탬프에는 어떤 영향을 주는지 궁금함. 특히 유지보수 모드이거나 거의 관리되지 않는 것들에 대해서
    내가 하는 일에는 이 정도 정밀도가 필요 없지만, 분명 필요한 분야는 있을 것임

    • UNIX 타임스탬프는 윤초를 완전히 무시하고 없는 것처럼 취급함
      그래서 윤초가 삽입될 때는 UNIX 타임스탬프로 참조할 수 없는 물리적 초가 생길 수 있고, 윤초가 삭제될 때는 실제로 존재하지 않는 초에 대한 UNIX 타임스탬프가 생길 수 있음
    • 윤초가 추가될 때마다 Google은 서버 시계를 더 긴 기간, 보통 몇 시간에 걸쳐 느리게 또는 빠르게 돌려서 NIST 어딘가에 있는 순백금 완전 구형 괘종시계와 천천히 다시 맞췄음: https://developers.google.com/time/smear
    • time()과 clock_gettime(CLOCK_REALTIME) 결과는 윤초의 영향을 받음
      새 윤초는 NTP를 통해 시스템에 도달함. 아쉽게도 NTP는 윤초가 도입될 것이라는 표시 플래그만 배포하고 오프셋 자체는 배포하지 않음. 하지만 배포되는 시간 자체가 이미 윤초의 영향을 받기 때문에 NTP 클라이언트가 꼭 알 필요는 없음
      반대로 GPS와 PTP 같은 다른 시간 동기화 방식은 윤초의 영향을 받지 않는 시간 척도를 쓰고 UTC 오프셋을 추가 정보로 배포함. 받은 시간을 끝에서 수정하는 것은 클라이언트 몫임. 커널에는 윤초를 위한 clock_adjtime() 파라미터가 있음
      NTP 클라이언트가 있는 수동 시스템이라면 실행 중에 새 윤초에 맞춰 시간이 바뀜. Linux는 UTC 시간을 우선으로 다뤄서 이것이 RTC 장치에 저장되고 재부팅 후에도 유지됨
      CLOCK_TAI는 TAI 시간을 반환해야 할 것처럼 보이지만, 일반 Linux 데스크톱·서버 배포판에서는 오프셋조차 설정하지 않아 CLOCK_REALTIME과 같은 시간을 반환할 정도로 2급 취급임
      /etc 안에는 어떤 패키지에 포함된 윤초 목록 파일이 있어서, 이 파일을 갱신하려면 시스템 업데이트가 필요함. 전통적인 NTP 소프트웨어가 이 패키지를 동적으로 갱신한다고는 생각하지 않음. 다만 이 파일을 쓰는 소프트웨어도 많지 않음
      어떤 init 서비스 스크립트가 이를 파싱해 커널 UTC 오프셋을 설정한다면, 업데이트 전까지 시스템의 CLOCK_TAI가 나머지 세계보다 1초 늦을 수 있음. 하지만 내가 아는 한 Linux의 UTC 시간에는 어떤 영향도 주지 않음

  • “시간의 측정과 배포를 책임지는 기관들에게”라는 문구는 역대급 전문임

    • 더 좋은 건 그 조직 이름이 International Earth Rotation Service라는 점임
    • 여러 해 동안 USNO에서 각종 정밀 시간 산출물을 총괄하던 리더십 직함이 “Director of the Directorate of Time”이었음
    • Douglas Adams 소설에 나올 법한 표현임
    • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
      직함마저 SF 같음

  • UTC-TAI 오프셋이 -37초로 유지된다면 UTC-GPS 오프셋도 -18초로 유지된다는 뜻임
    TAI와 GPS는 두 체계 사이에 일정한 19초 오프셋이 있음

  • 이런 상황에서 Spanner 같은 시스템은 어떻게 되는지 궁금함
    골칫거리인지, 아니면 별일 아닌지?

    • 큰 문제임. 이를 다루는 가장 흔한 방식은 스미어링(smearing) 이라고 부르며, “윤초” 전 24시간 동안 각 초의 길이를 조정함
      엄격한 순서 보장이 필요한 시스템에서는 각 장치가 전역 시계와 동기화를 유지하고, 시계 주기의 길이만 아주 조금 달라지므로 작동함. 실제로 원래 Spanner 논문에 있었던 것으로 기억함
      드문 시스템들은 단조 발진기 초를 쓰고 지구 자전 초를 무시하기도 하지만, 언젠가 이를 실제 시간으로 변환해야 한다면 시간이 지날수록 재앙이 누적되며 일반적으로 좋은 생각이 아니라고 여겨짐
    • 윤초는 윤일처럼 정기 일정으로 추가되는 것이 아니라 지구의 물리 측정에 따라 달라짐
      그래서 포괄적인 시간 관리가 있는 고신뢰성 시스템은 이런 선택에 크게 흔들리지 않을 것 같음

  • Temporal API가 있으면 브라우저나 Node.js 등이 그 시점 주변의 연산에서 시간을 올바르게 처리할 수 있을까? 아니면 계산을 망치지 않으려면 업데이트가 필요할까?

    • Temporal API는 윤초를 무시하는 Unix/POSIX 타임스탬프를 기반으로 하는 것 같음. Unix 시간에서 하루는 항상 86400 “초”임
      그래서 데이터베이스 없이도 과거와 미래의 UTC 달력 계산을 쉽게 할 수 있고, 반드시 소수 초를 다룰 필요도 없음. 윤초는 운영체제가 1초를 반복하거나 건너뛰거나, 윤초 전후 일정 기간 동안 초의 길이를 조정하는 방식으로 처리함
      대부분의 날짜·시간 API는 기본적으로 비즈니스 기능을 위한 달력 및 벽시계 연산을 지원하도록 설계됨. 과학적 목적에 필요한 SI 초가 필요하다면, 하드웨어 수준까지 필요한 의미를 제공하고 보장하는 별도 API와 기능을 써야 함
      마찬가지로 스레드 sleep 같은 소프트웨어 기능을 위한 타이머가 필요하다면 단조 시계 같은 전용 인터페이스를 써야 함. 윤초가 단계적으로 사라져도 이 상황은 크게 달라지지 않음. 윤초 조정이 있든 없든, 예컨대 뮤텍스 알고리즘이 Unix 타임스탬프에 의존하는 것은 예전에도 틀렸고 앞으로도 틀림

  • 내 얘기 좀 들어봐. 적도에 제트 엔진을 달고 180도 돌려서 시간을 얻거나 잃으면 됨. 그리고 그걸 내 snooze 버튼에 연결하면 됨

    • Superman이 지구 주위를 엄청 빠르게 여러 번 도는 게 더 쉽지 않을까? 그러면 엔진 유지보수를 걱정할 필요가 없음
    • 실제로는 아주 많은 양의 물을 옮기면 측정 가능한 영향을 줄 수도 있음. 예를 들어 California Central Valley 대수층을 고갈시키는 것처럼
    • 문제는 미래 사회가 그 엔진들을 성간 탐사선용으로 회수하는 것임. 이 문제는 Larry Niven의 책 시리즈에서 다뤄졌음
    • 다 같이 동시에 점프하면 될 것 같기도 함. 필요한 건 1~2초뿐 아닌가?
    • 한동안 윤초를 넣을 필요가 없었던 걸 보면 이 방법이 먹힌 모양임

  • “UTC와 TAI의 차이는 2017년 1월 1일 0시 UTC부터 별도 공지까지 UTC-TAI = -37s”라고 되어 있음
    이 말은 원자시계가 태양시계보다 37초 뒤처진다는 뜻인가? 2017년을 언급한 이유도 이해가 안 됨

    • 오히려 반대에 가까움
      UTC의 하루는 정확히 86400 SI초로 정의됨. 하지만 실제 평균 태양일은 몇 밀리초 더 김. 지구 자전의 불규칙성 때문에 차이는 일정하지 않지만, 평균 차이는 시간이 지나며 천천히 커질 것으로 예상됨. SI초는 원자시계로 세므로 UTC는 원자시계의 86400초마다 하루를 넘김
      반면 평균 태양이 정오에 도달할 때마다 하루를 넘기는 태양시계는 UTC보다 몇 밀리초 늦게 하루를 넘김. 실제 태양은 한 해 동안 하늘을 가로지르는 속도가 달라지므로 평균 태양을 써야 함
      이를 다르게 말하면, 태양시계가 정확히 86400초라고 부르는 각 기간은 원자시계 기준으로는 몇 밀리초 더 김
      이런 일이 매일 누적되다가 거의 1초가 되면 UTC에 윤초를 삽입해서 그날 하루를 86400초가 아니라 86401초로 만듦. UTC는 단순히 원자시계 시간을 세는 것만이 아니라, 많은 인간 활동이 하늘의 태양 위치와 연결되어 있으므로 태양과도 동기화되어야 하기 때문임
      인간은 “태양과 동기화”를 “평균 태양과 1초 이내”로 정의했음. 즉 UTC 정오가 본초자오선에서의 평균 태양 정오와 1초 이내이기를 원함
      따라서 37초는 윤초를 쓰지 않았다면 평균 태양 정오가 UTC 정오보다 얼마나 뒤처졌을지를 뜻함. UTC 정오일 때 평균 태양은 하늘에서 본초자오선을 지나기까지 아직 37초 부족했을 것임
    • Wikipedia에 따르면 2016년 12월이 마지막으로 윤초가 삽입된 때임: https://en.wikipedia.org/wiki/Leap_second
    • 2017년을 언급한 건 그때 마지막으로 오프셋이 바뀌었기 때문일 것임. 그래서 -37초가 그때부터 계속 유효한 상태임
답변달기