GN⁺: "Australia/Lord_Howe"는 가장 이상한 타임존임
(ssoready.com)- 타임존은 복잡하지만, 컴퓨터가 이를 구현해야 하므로 유한한 범위 내에서만 이상함.
-
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
가 있음.
Hacker News 의견
-
tz 데이터베이스는 빅뱅 이전의 시간대 전환을 계산하지 않음. 빅뱅 이전의 타임스탬프는 물리적으로 의심스러움
- 예를 들어, Glib는 브라질의 1913년 규칙을 여전히 적용하여 상파울루 타임스탬프를 계산함
- 빅뱅 이전의 윤초도 허용되지 않음
-
아프리카/아디스아바바 시간대는 에티오피아에서 아무도 따르지 않음
- 현지인들은 시간을 6시간씩 오프셋하여 사용함
- AM 주기는 새벽에 시작하고, PM 주기는 황혼에 시작함
-
프로그래밍 언어가 61초의 분을 표현할 수 없다는 것은 사실이 아님
- Raku는 윤초를 지원함
- Perl 5의
DateTime.pm
도 윤초를 지원하며, 이는 복잡성을 증가시킴 - 윤초는 거의 사용되지 않으며, 코드의 복잡성을 증가시킴
-
아시아/예루살렘 시간대는 종교와 국가 문제로 인해 복잡함
- 종교적 이유로 일광 절약 시간이 매년 협상으로 결정됨
- Rosh HaShanah에 일광 절약 시간이 끝나지 않도록 예외가 존재함
-
미국 주소를 기반으로 현지 시간을 찾는 함수 작성 경험
- 주와 시간대를 정적으로 매핑하는 것은 엣지 케이스 때문에 어려움
- ZIP 코드와 UTC 오프셋을 매핑한 CSV를 구매하여 사용함
- 미국의 해외 영토와 군사 기지 때문에 복잡한 시간대가 존재함
-
팔레스타인의 시간대는 고정된 날짜 없이 매년 정부가 일광 절약 시간 시작과 종료를 발표함
- 일주일도 안 되는 공지로 인해 다양한 문제가 발생할 수 있음
-
시간대 소프트웨어의 유연성에 대한 흥미로운 읽을거리
- 일광 절약 정책이 60분 조정에 국한되지 않을 수 있음
- 국가가 연중 지속적으로 변하는 오프셋을 가질 수 있음
-
정부가 일광 절약 시간을 폐지하고 다음 해에 시간대를 이동시키면 혼란이 발생함
- Android 앱 개발 시 시스템 이미지에 내장된 시간대 데이터베이스로 인해 문제가 발생함
-
tz 데이터베이스는 UTC와의 차이를 기록하는 diff의 diff임
- 업데이트가 이루어지며, changelog는 git에 저장됨
- diff^4로 표현할 수 있음
-
30분의 일광 절약 시간 차이는 가장 이상한 시간대가 아님
- 남극/트롤, 모로코 및 가자 시간대는 시스템이 표현할 수 없는 규칙을 가짐
- 윤초는 프로그래머에게 유용하지 않으며, 대부분 무시됨