"Australia/Lord_Howe"는 가장 이상한 타임존임

• 타임존은 복잡하지만, 컴퓨터가 이를 구현해야 하므로 유한한 범위 내에서만 이상함.
  • Asia/Kathmandu는 UTC로부터 이상한 오프셋을 가짐.
  • Africa/Casablanca는 시간대 모델에 잘 맞지 않아 하드코딩됨.
  • America/Nuuk는 -01:00에서 서머타임을 시작함.
  • Africa/Cairo와 America/Santiago는 24시(0시가 아님)에 서머타임을 시작함.
  • Australia/Lord_Howe는 가장 이상한 서머타임 규칙을 가짐.

PGXIIREAM: 교황 그레고리오 13세가 모든 것을 지배함

• 대부분의 세계는 그레고리오력에 기반한 시간 시스템을 사용함.
• 그레고리오력은 태양의 위치를 연중 일정하게 유지하는 데 매우 유용함.
• UTC는 그레고리오력의 현대적 공식화로, 전 세계가 이를 기준으로 시간을 설정함.

윤초는 중요하지 않음

• 지구의 회전이 느려지고 있어 윤초를 추가하여 이를 보정함.
• 윤초는 프로그래밍 언어에서 61초를 표현하지 않기 때문에 무시해도 됨.
• 클라우드 제공자는 윤초 동안 시계를 느리게 돌려 문제를 해결함.

이상한 시간대

Asia/Kathmandu는 이상한 오프셋을 가짐

• 네팔은 UTC보다 5시간 45분 앞서 있음.
• 컴퓨터는 IANA 시간대 데이터베이스를 통해 이 정보를 알 수 있음.

PDT나 CET 같은 문자열은 의미가 없음

• 시간대 식별자는 모호할 수 있으며, 많은 시간대가 동일한 식별자를 공유함.

서머타임이 있는 시간대는 어떻게 표현되는가?

• 서머타임 전환 규칙은 복잡하며, 컴퓨터는 이를 기반으로 현지 시간을 계산함.

Africa/Casablanca와 Asia/Gaza는 달을 따르지만, 시간대는 태양을 따름

• 모로코와 가자는 라마단에 따라 서머타임을 조정하며, 이는 하드코딩됨.

America/Nuuk는 -1시에 서머타임으로 전환함

• 그린란드는 유럽과 같은 시점에 서머타임을 시작하지만, 현지 시간으로는 -1시에 시작함.

America/Santiago와 Africa/Cairo는 24시에 전환함

• 이들 시간대는 24시에 서머타임을 전환하며, 이는 다음 날로 넘어가는 것을 의미함.

Australia/Lord_Howe는 가장 이상한 서머타임 전환을 가짐

• Lord Howe Island는 30분 서머타임 전환을 가짐.

GN⁺의 정리

• 시간대는 복잡하지만, 컴퓨터가 이를 구현해야 하므로 유한한 범위 내에서만 이상함.
• Australia/Lord_Howe는 30분 서머타임 전환으로 가장 독특한 시간대임.
• 이 기사는 시간대의 복잡성을 이해하는 데 유용하며, 프로그래머에게 흥미로울 수 있음.
• 유사한 기능을 가진 프로젝트로는 tzdb가 있음.

[GN⁺]

Hacker News 의견들

• tz 데이터베이스에서 가장 재미있는 부분은 빅뱅 시점 추정치가 들어 있고, 빅뱅 이전에 발생하는 시간대 전환은 계산하지 않도록 되어 있다는 것임
  https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b...의 커밋 메시지도 “빅뱅 이전 타임스탬프는 물리적으로 의심스러우니 생성하지 말자”는 취지였고, 곧이어 별도 커밋으로 빅뱅 이전의 윤초도 금지됨

  • 예전에 Linux/Unix date의 과거 날짜 의미를 다룬 긴 매뉴얼 페이지가 있었음
    15세기쯤의 예시와 함께 어떤 왕이 특정 주/월을 좋아해서 반복하라고 명령했다거나, 다른 왕이 특정 주를 싫어해서 달력에서 지웠다는 식의 이야기가 있었고 꽤 눈이 트이는 읽을거리였는데, 지금은 찾을 수 없음
  • 꽤 실용적인 결정처럼 보임. 기여자들 사이에서 핀 끝의 천사 논쟁 같은 무의미한 논쟁을 미리 막는 좋은 방식임
    다르게 말하면 “빅뱅 이전의 순간은 이 라이브러리의 범위 밖이므로, 어떤 알고리즘이 빅뱅 이전에서만 잘못된 값을 내면 그 알고리즘은 받아들일 수 있고 개선/교체할 필요가 없다”는 결론임
  • 정말 멋진 부분이지만, 별개로 tzdb가 Unix epoch 이전까지 다루려는 시도에는 약간 회의적임
    그 부분의 버그 대비 효용이 크지 않아 보이고, tzdb의 지저분한 복잡성 대부분은 zic에 있음. 가끔은 zic가 다른 사람들이 의존할 수 있는 산출물이 아니었으면 더 나았겠다는 느낌이 듦
  • TZ 데이터베이스의 재미있는 이스터 에그임. 처음 들었지만, 그렇게 오래된 시간대 데이터를 계산할 일이 얼마나 있을까 싶음
    시간대 이론이 낡아지기 전에 시간대 자체가 사라지면 좋겠음

• 가장 이상한 시간대는 Africa/Addis_Ababa라고 봄. 정작 에티오피아 현지인들은 그 방식을 따르지 않음
  현지에서는 시간을 6시간 밀어서 새벽, 즉 오전 6시에 AM 주기가 시작되고, 해질녘인 오후 6시에 PM 주기가 시작됨
  https://en.wikipedia.org/wiki/Time_in_Ethiopia

  • 케냐를 포함한 동아프리카 전역에서 흔한 방식임. 밤은 오전 6시에 끝나고, 오전 7시는 하루의 첫 번째 시간인 saa moja가 됨
    마찬가지로 하루는 오후 6시, thenashara에 끝남. 직관적으로는 영어권 시계보다 훨씬 말이 되고, 언어 안에 박혀 있어서 시간 혼동도 드묾
  • 에티오피아의 시간 계산은 전반적으로 특이함
    https://en.wikipedia.org/wiki/Ethiopian_calendar
    에티오피아 달력은 30일짜리 12개월과, 13번째 달을 이루는 5일 또는 6일의 윤일성 날짜로 구성됨
  • 로마인들이 시간을 이해하던 방식과 매우 비슷함. 북아프리카가 여러 속주였던 시절의 오래된 흔적인지 궁금함
    https://en.wikipedia.org/wiki/Roman_timekeeping
  • 적도 근처 국가라면 하루 주기를 정의하는 방식으로 그렇게 비합리적이지는 않음
  • 일본도 자정 이후에 닫는 시설 같은 맥락에서는 비슷한 방식을 씀: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
    영어권도 예전에는 3월 25일에 해가 바뀌었음: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
    둘 다 기술적으로는 tzdb가 다룰 수 있는 대상이 아님. tzdb는 시민 시간(civil time)을 다루지, 달력이나 다른 계산 방식까지 다루지는 않음

• Asia/Jerusalem의 이상함은 일광절약시간제가 정교분리 이슈와 크게 얽혀 있기 때문임. 종교적인 사람들은 해질녘에 시작되는 명절에 맞춰 근무일이 편리하길 원함
  그래서 2000년대 중반까지 수십 년 동안 일광절약시간제는 종교 정당과 세속 정당 사이의 매년 협상 결과였고, 전환일 직전에야 결정되어 문제가 자주 생겼음
  아직도 Rosh HaShanah에 일광절약시간제가 끝나지 않도록 하는 예외가 들어 있어서, 미래 규칙이 복잡해 보이는 것 같음

  • 일광절약시간제의 장점이 제한적이고, 특히 비교적 남쪽에 있는 나라라면 완전히 폐지하지 않은 이유가 궁금함
    EU가 결국 폐지에 성공하면 따라갈 수도 있을 듯함
  • 유월절 때문임. Seder라는 큰 축하 식사는 자정 이후까지 이어지고, 아이들에게도 매우 중요한 행사임
    그래서 일광절약시간제가 이미 늦게 끝나는 행사를 더 늦게 만들기를 원하지 않음. 또 Yom Kippur 금식일에는 금식이 1시간 더 일찍 끝나길 원했음. 이 날짜들에 맞추려다 보니 일광절약시간제 기간이 너무 짧아져 협상이 필요해짐
  • 더 이상 예외는 없음. IDT는 2013년에 10월 마지막 일요일까지로 연장됨

• “프로그래밍 언어가 61초짜리 분을 표현하지 못한다”는 말은 사실이 아님. 누군가 이미 Raku가 윤초를 지원한다고 했고, 그건 부분적으로 내 탓일 수 있음
  Perl 5의 가장 인기 있는 날짜/시간 라이브러리인 DateTime.pm이 윤초를 지원하기 때문이고, 내가 DateTime.pm을 만들며 그 지원을 구현했음
  돌아보면 거의 확실히 실수였음. 윤초에 관심 있는 사람은 거의 없고, “60초를 더하면 1분을 더한 것과 왜 가끔 다르지?” 같은 이상한 혼란만 만들어냄
  특히 second => 60이 유효한지 검증하려 했기 때문에 코드가 훨씬 복잡해졌음. 생성자는 시간 구성 요소와 임의의 시간대를 받으므로, 윤초 표를 확인하려면 UTC로 변환해야 하는데, 그 변환 자체가 역사적 이유로 윤초를 포함한 값들과 얽히게 됨
  아주 작은 이득을 위해 거대한 난장판이 됐고, Raku의 표준 날짜/시간 라이브러리도 Perl 5의 DateTime.pm에서 많이 빌려온 듯해서 같은 나쁜 설계 결정을 일부 물려받았다고 봄

  • 그렇게 구현했고 나중에 더 우아한 해법을 돌아볼 수 있게 된 점은 좋음
    처음에는 어떤 사고 과정이었는지 궁금함. 문제에 너무 몰입했던 건가? 문제에 너무 가까이 있고 오래 집중하면, 망가지기 전에 고치는 즐거움이 앞서 이런 일이 생기곤 함
  • Raku에는 Instant 클래스가 있음
    “Instant는 원자초와 그 소수 부분으로 측정되는 특정 순간이며, 어떤 epoch에도 묶여 있거나 aware하지 않다”는 식으로 정의됨

• 올해 초에 미국 주소가 주어졌을 때 현재 현지 시간을 찾는 함수를 작성해야 했음. 순진한 방식은 주(state)를 시간대에 정적으로 매핑하는 것이지만, 그렇게 못 하게 만드는 예외가 꽤 있음
  해당 애플리케이션에서는 비용과 속도가 중요해서, 모든 미국 ZIP code를 UTC 오프셋과 일광절약시간제 준수 여부 등에 매핑한 CSV를 몇 달러에 샀음
  pytz는 IANA 시간대 이름을 받기 때문에 결국 오프셋과 일광절약시간제 정보를 특정 시간대에 수동 매핑해야 했고, 미국 해외 영토와 군사기지 때문에 Etc 시간대 같은 이상한 의미론도 필요했음
  [1] https://en.wikipedia.org/wiki/Tz_database#Area

  • 주 단위는 해상도가 완전히 잘못됐음. 미국 시간대는 카운티와 원주민 보호구역 경계를 따라감
    ZIP code도 아마 충분할 수 있지만 조심해야 함. 주소 수가 너무 많지 않다면, 더 견고한 방식은 역지오코딩한 뒤 시간대 경계 도형에서 IANA 식별자를 얻는 라이브러리를 쓰는 것임
    https://github.com/RomanIakovlev/timeshape는 예전 동료가 관리하는데, 내부에서 했던 작업 일부를 오픈소스로 공개할 수 있었음
  • 1985년에 대학을 갓 졸업한 젊은 엔지니어였을 때, 미국의 여러 레이더 사이트에서 자기 테이프로 녹화한 원격측정 데이터를 합치는 일을 맡았음
    한두 시스템은 데이터를 현지 시간으로 찍었고 나머지는 UTC를 썼음. 일광절약시간제를 처리할 알고리즘을 만들려고 옛 Farmers' Almanac을 샀는데, 규칙을 읽고 절망했음
    달력에는 전환의 명목상 규칙이 있었지만, 의회 개입 때문에 해마다 조정되어 왔고 앞으로도 그럴 거라는 각주가 있었음. 상사에게 “의회의 미래 표결을 예측하는 알고리즘을 쓸 수 있다면 억만장자가 되어 이 엔지니어 일을 그만뒀을 것”이라고 말했음
    결국 최근의 알려진 전환과 미래의 명목상 규칙을 코딩했던 것 같음. 모두가 네트워크에 연결되기 전이고, 코드는 VAX 같은 독립형 컴퓨터에서 돌았으니 다른 방법이 별로 없었음
    각자 유효성 및 측정 품질 저하 상태를 가진 세 추적 데이터 소스를 합치는 작업도 악몽이었지만, 그래도 의회의 미래 행동을 예측하는 것보다는 쉬웠음
  • 좋은 접근은 ZIP code를 US/Eastern 같은 이름 있는 시간대에 매핑하는 것임. 이후 UTC 오프셋이 필요하면 pytz로 해당 날짜에 시간대를 적용해 오프셋을 얻으면 됨
    이름 있는 시간대는 고정적이라 특별함. -05:00 같은 UTC 오프셋 시간대나 EST 같은 약칭은 일광절약시간제 때문에 특정 위치에서 시간에 따라 고정적이지 않음
    누군가에게 시간대를 물으면서 오프셋이나 약칭을 선택지로 주면 모두가 혼란스러워짐
  • 올해 초 비슷한 일을 했는데, 주소를 위도/경도로 바꾸는 지리 위치 서비스를 쓰고, 다시 위도/경도에서 시간대를 구했음. 단일 시간대 주에는 단축 경로를 뒀음
    위도/경도 → 시간대 변환에는 이 Python 라이브러리를 사용함: https://github.com/jannikmi/timezonefinder
    데이터 출처도 꽤 품질 높은 소스처럼 보였음: https://github.com/evansiroky/timezone-boundary-builder/rele...
  • Etc 식별자는 정말 조심해야 함. 특히 모든 식별자를 그대로 사용자에게 노출하려 했다면 더 그렇음
    해당 파일에는 “POSIX는 그리니치 서쪽을 양수로 두지만, 많은 사람은 그리니치 동쪽을 양수로 기대한다. 예를 들어 TZ='Etc/GMT+4'는 약칭 -04를 쓰고 UT보다 4시간 늦은, 즉 그리니치 서쪽을 의미하지만 많은 사람은 UT보다 4시간 빠른 동쪽으로 기대한다”는 주석이 있음

• 팔레스타인의 시간대도 꽤 이상함
  https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
  일광절약시간제가 있지만 날짜가 고정되어 있지 않고, 정부가 매년 시작과 종료 시점을 발표함. 때로는 일주일도 안 남기고 발표해서 온갖 흥미로운 문제가 생길 수밖에 없음

  • 같은 물리적 장소에 사는 두 사람이 민족적·지정학적 정체성에 따라 서로 다른 현재 시간을 따르는 현상이 생김
    이스라엘과 팔레스타인의 일광절약시간제 시작·종료일이 반드시 같지는 않음
  • 지금도 그런지는 모르겠지만 브라질도 예전에는 그랬음. 그것 때문에 비행기를 거의 놓칠 뻔한 적이 있음
  • 실제 글에 나오는 내용이고, 라마단과 연결되어 있음
  • 정치 얘기를 깊게 하지 않더라도, 왜 일광절약시간제에 노력을 우선 투입하는지 이해가 잘 안 됨. 다른 걱정거리가 훨씬 많아 보임

• 1시간이 아니라 30분 차이인 일광절약시간제를 “가장 이상한 시간대”라고 하기엔 기준이 너무 낮다고 봄
  거의 다른 것들이 더 이상함. Antarctica/Troll이 확실히 더 이상하게 들리고, 모로코와 가자의 시간대는 기존 시스템으로 표현할 수 없을 정도라 적어도 다른 종류의 규칙이 있음. Apple의 금지 목록에 오른, 특정 날짜 전날 전환되는 시간대들도 뭔가를 깨뜨릴 만큼은 이상함
  윤초에 대해서는 동의함. 프로그래머가 알아야 할 유용한 지식이라기보다 거의 잡학임. 컴퓨터는 윤초를 스미어 처리하고, 언제 일어났는지도 모름. 완전히 잊고 살아도 됨
  다만 국가들이 윤초를 무시하던 방식에서 고려하는 방식으로 전환한 적이 있어서, 몇십 년 전 호주의 GMT+x에서 UTC+x로의 변경은 윤초를 무시하던 것에서 포함하는 것으로 넘어간 전환이었음. 이 사실이 거의 보편적으로 무시되는 건 오히려 나은 일일지도 모름

  • 대체로 윤초가 잡학이라는 데 동의함
    하지만 어떤 대형 조직이 “우리 서버는 GPS 동기화와 직접 개발한 PCIe 루비듐 원자시계 카드 덕분에 밀리초 미만의 시간 정확도를 가진다”고 말하면서도, 동시에 “윤초는 하루에 걸쳐 스미어하므로 실제로 서버 시간이 ±0.5초 틀려도 상관없다”고 하는 건 늘 좀 웃김
    [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
    [2] https://engineering.fb.com/2020/03/18/production-engineering...
  • 라마단 날짜는 잘 알려진 값이 아님. 지구상의 특정 지역에서 달을 실제로 볼 수 있는지에 기반하기 때문임
    예를 들어 하늘이 매우 흐리면 달이 어디 있든 볼 수 없음. 이 때문에 국가 운영에 달력을 구현할 때 문제가 생김
    이슬람력을 공식 채택한 많은 국가는 특정 위치에서의 예상 가시성을 기반으로 미리 계산한 근사 날짜를 사용함. 따라서 이슬람력은 사실 하나가 아니라 관측 이슬람력과 예측 달력이라는 둘에 가깝고, 둘 다 실제 또는 예측 관측이 이루어지는 위치에 의존함
    모로코나 가자가 어떻게 하는지는 모름
  • Antarctica/Troll은 그렇게 이상하지 않음. 실제로는 짧은 여름 동안 케이프타운 시간을 쓰고, 나머지 기간에는 노르웨이 시간을 씀
    다만 노르웨이 시간이 하필 일광절약시간제를 사용함
  • 윤초는 대체로 잡학이지만, 여러 당사자가 시간 순서에 대해 정확히 합의해야 하는 애플리케이션에서는 결정적으로 중요해짐. 대표적인 예가 금융 거래임
    많은 시장은 윤초 동안 문을 닫았고, 많은 은행은 오류 위험을 줄이기 위해 현지 시간 변경 시 모든 거래를 여전히 중단함
    별로 신경 쓰지 않는 애플리케이션에서도 윤초 관련 버그가 놀랄 만큼 많이 있었고, CGPM이 윤초 폐지를 결정한 데는 좋은 이유가 있음
    https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
  • Troll을 찾으러 왔음. 내가 알기로는 겨울 일광절약시간제가 있는 유일한 곳이고, 이름 덕분에 추가 점수도 있음

• 시간대 소프트웨어의 곡예를 다룬 훌륭한 글임. 정말 꽤 유연함
  전부 자동화된 유한한 오프셋이라면, 일광절약 정책이 꼭 60분 조정에 맞춰질 이유는 없음
  어떤 나라가 1년 내내 연속적으로 변하는 오프셋을 쓰기로 할 수도 있지 않을까? 오프셋 조회 테이블은 훨씬 길어지겠지만, 이렇게 하면 일광절약시간제를 “해결”할 수도 있음. 계속 조금씩 조정되니 윤초처럼 알아차리지 못할 것임
  아날로그 시계에 의존하는 사람들은 더 이상 매번 같은 방향으로 조정하지 않을 수도 있음

  • 전자 기기의 시계 동기화가 흔해진 이후로, 6개월 동안 매달 첫 번째 일요일에 10분씩 앞으로, 나머지 6개월 동안 매달 첫 번째 일요일에 10분씩 뒤로 조정하자고 들어주는 사람마다 제안해 왔음
    한 달에 한 번 10분 변경은 적응하기 훨씬 쉽고 거의 눈치채지 못하며, 놓쳐도 1시간 틀리는 것만큼 큰일은 아님
  • 그 길로 가면 논리적 결론은 시간대 개념 자체를 없애고 현지 태양시로 돌아가는 것임
  • 일광절약시간제를 “해결”하는 가장 쉬운 방법을 무시하고 있음
    일광절약시간제를 그만두면 됨. 개인적으로는 영구 일광절약시간제보다 영구 표준시를 선호하지만, 1년에 두 번 시계를 바꾸는 일을 멈출 수만 있다면 받아들일 수 있음
  • 인도는 UTC+5:30이고 일광절약시간제를 하지 않아서 세계와 상호작용할 때 흥미로움
    물론 중국은 유명하게도 그렇게 넓은데 시간대가 하나뿐이라 내부적으로도 외부적으로도 흥미로운 상황을 만듦
  • 이론적으로는 tzdb로 표현할 수 있음. 물론 문제를 일으킬 것임
    TZif 데이터 형식에 명확히 드러나지 않는 정말 중요한 가정은, 현지 시간에서 UTC 시간으로 갈 때 가능성이 최대 두 개뿐이라는 것임
    많은 소프트웨어가 이 가정에 기대고 있고, 예를 들어 java.time.LocalDateTime에는 withLaterOffsetAtOverlap()이 있음: https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
    이는 오전 2:30이 무엇을 의미하는지 애매할 때 가능한 해가 전후 일광절약시간제 두 개뿐이라고 암묵적으로 가정함. 어떤 시간대가 오전 2시에 한 번 뒤로 돌리고 2:15에 또 뒤로 돌리는 식으로 세 개 이상의 해를 만들면, 많은 것들이 이를 표현하지 못함

• tz 데이터베이스에서 마음에 드는 점은 기술적으로 diff의 diff라는 것임
  각 시간대와 UTC의 차이가 역사적으로 어떻게 달라졌는지를 저장하니 diff^2라고 볼 수 있음. 그런데 tz 데이터베이스는 업데이트도 받으므로, 그 커밋은 diff의 diff의 diff, 즉 diff^3임
  더 갈 수 있음. 변경 로그가 있고 그 변경 로그가 git에 저장되므로, tz 변경 로그에 대한 커밋은 UTC에 대한 변경 목록의 변경 목록의 변경 목록에 대한 변경인 diff^4임

  • UTC, 더 넓게는 시간 측정 자체도 diff라는 점을 빼먹었음
  • diff의 diff는 그냥 diff 두 개임. diff의 곱이 아님

• 거의 모든 날짜/시간은 실제로는 감시 중인 매칭 규칙 집합이라는 프레이밍이 핵심이라고 봄
  매칭이 트리거되기까지 몇 초가 걸릴지 추측할 수는 있지만, 실제로 일어나기 전까지 완전히 확신할 수는 없고, 어떤 경우에는 아예 정확히 일어나지 않을 수도 있음
  그 다음 절반은 “지금부터 X초 뒤에 일어날 것 같다”는 델타 추측을 “그때 당신의 시간대 시계는 Y라고 표시할 것 같다”로 되돌리는 작업임
  어떤 시간대가 이벤트를 제어하는지와, 어떤 시간대에 표시되는지를 계속 추적하는 걸 잊지 말아야 함
  [1] UTC 추정치는 윤초만큼 앞뒤로 빗나갈 수 있음. TAI가 더 안전하지만, 누군가 세슘 원자의 동작을 바꾸는 흥미롭고 새로운 뭔가를 발견하면 달라질 수 있음
  [0] 예를 들어 국가가 사라져 시간대가 없어질 수도 있음. 또는 시계가 1:00에서 2:00으로 건너뛰어 빠진 1시간 때문에 1:30~2:00 구간이 정확히 일어나지 않을 수도 있음