Hacker News 의견

• DST(일광 절약 시간제) 는 완전히 잘못된 제도라고 생각함
  아무런 문제도 해결하지 못하고 오히려 불편만 초래함
  그냥 표준시(겨울 시간) 으로 고정하고, 대신 근무 시간을 여름 시간대처럼 한 시간 앞당기면 됨
  예를 들어 가게를 7시 대신 6시에 열고 10시 대신 9시에 닫는 식임
  어차피 1년에 두 번씩 적응 기간이 있으니, 한 번만 바꾸면 됨
  나는 퇴근 후에 햇빛을 더 보고 싶음. 겨울에는 특히 더 그렇고, 출근길에 해가 떠 있는 건 상관없음
  실내에 9시간 갇혀 있을 테니까, 자유 시간이 있을 때 햇빛을 보고 싶음

  • 모두가 DST를 싫어하지만, 제안된 대안들은 이미 시도된 적이 있음
    예를 들어 1973~1975년 미국의 연중 DST 실험이 있었음
    처음엔 에너지 절약과 범죄 감소 등의 이유로 찬성 여론이 높았지만,
    어두운 아침 통학길 사고로 여론이 급격히 악화되어 결국 폐지되었음
    (Wikipedia 인용)
  • 시계를 옮기지 말고 영업시간을 바꾸자는 건 결국 같은 효과를 내는 것 아닌가 하는 의문이 있음
    결국 더 큰 시간 이동을 원한다는 말처럼 들림
  • ‘겨울 시간’이라는 용어는 사실 존재하지 않음
    표준시와 일광 절약 시간만 있을 뿐임
    ‘겨울 시간’을 항상 유지하자는 표현은 심리적으로 매력적이지 않음
  • DST는 단순히 태양이 뜨는 시각에 맞추려는 임시방편일 뿐임
    사람들은 해가 떠 있을 때 하루를 시작하길 원함
    프로그래머들이 DST 때문에 고생하지만, 그건 엣지 케이스 처리를 잘 해야 하는 문제라고 생각함
  • 표준시냐 일광 절약 시간이냐의 논쟁은 결국 근무 시간 선택의 자유가 부족해서 생기는 문제임
    사람마다 수면 패턴이 다르니, 각자 맞는 근무 시간을 선택할 수 있으면 갈등이 줄어들 것임

• 예전에 reddit 서버를 세팅할 때, 전부 Arizona 시간대로 설정했음
  Arizona는 DST를 사용하지 않아서, 캘리포니아와 1시간 차이만 있음
  UTC를 쓰지 않은 이유는 로그를 읽을 때 ‘8을 빼는 것보다 1을 빼는 게 쉽기 때문’이었음
  지금은 글로벌 팀이 생겨서 UTC로 바꾼 상태임

  • 비슷한 결정을 한 적이 있는데, 나중에 정리하느라 고생했음
    처음부터 전부 UTC로 통일하는 게 좋음
  • 하지만 Arizona처럼 시간대 정의가 바뀔 위험도 있음
    전 세계적으로 이런 변경이 자주 일어나서, 캘린더 앱 개발자 입장에서는 정말 골치 아픈 일임
  • 로그 뷰어 UI가 브라우저 언어 설정으로 12/24시간 형식을 강제하는 게 불만임
    UTC를 선택했으면 YYYY-MM-DD 24시간 형식을 이해할 줄 안다고 가정해야 함
  • Java에서는 JVM 단위로 기본 시간대를 설정할 수 있는데,
    조직 내에서 각자 PST로 바꿔 쓰다 보니 로그마다 시간이 달라지는 혼란이 생겼음
    결국 리더가 나서서 모든 애플리케이션과 DB를 PST로 통일시킴
  • UTC로 로그를 읽을 때 날짜가 바뀌지 않는 점은 여전히 헷갈림
    그래도 이제는 본능적으로 UTC를 해석하게 되었음

• 예전에 회사 서버를 BST(영국 여름 시간) 으로 설정하고 cron을 많이 썼는데,
  매년 두 번씩 혼란이 반복되었음
  결국 회사가 망할 때까지 고치지 못했음
  교훈은 간단함 — UTC를 써라, 특별한 이유가 없다면

  • 책상 위에 UTC 아날로그 시계를 두고 로그를 볼 때 참고함
  • 고객이 UTC에 있지 않다는 이유로 현지 시간대를 쓰는 경우도 있음
    예를 들어 사용량 제한 리셋이나 청구 배치 작업은 지역 시간 기준으로 돌아감
  • cron 자체를 쓰지 말고, 데이터와 고객 설정을 인식하는 스케줄러를 쓰는 게 낫다고 생각함
  • 어떤 보고서는 현지 시간 기준으로 필요함
    예를 들어 영국 8시 보고서는 DST에 따라 UTC 기준이 달라짐
    따라서 UTC만으로는 해결되지 않으며, 시간대 정보를 함께 저장해야 함
  • 금융권처럼 시장 개장 시간이 중요한 경우에는 UTC만으로는 부족함

• 일부 국가(Cuba, Egypt, Lebanon)는 DST 변경이 자정에 일어남
  (관련 링크)

  • DST 변경이 자정이 아닌 곳도 있다는 게 놀라웠음
    브라질에서는 00:00~01:00 또는 00:00~23:00에 바뀌는 게 일반적이었음
  • 시간대 규칙은 정말 예측 불가능한 일을 많이 함

• DST 조정일에는 사망률과 응급실 방문이 급증한다는 연구가 있음
  (ScienceAlert 기사)
  단순히 cron 문제를 넘어서, DST는 건강에도 해로운 제도임

• 이 문제는 오래전에 OpenBSD와 Debian에서 이미 해결된 적이 있음
  Debian의 cron(8) 매뉴얼에는 DST 조정 시 3시간 미만의 시간 이동 처리 로직이 설명되어 있음
  (패치 링크,
  매뉴얼,
  버그 리포트)

  • 그렇다면 원문 작성자는 이 패치가 적용되지 않은 배포판을 쓴 것 같음

• 자정(00:00) 에 작업을 예약하지 말라는 조언임
  날짜가 헷갈리기 쉬우니 00:01이나 01:45처럼 어정쩡한 시각을 쓰는 게 좋음

  • 나도 cron 작업을 XX:13, XX:23, XX:42처럼 설정함
    시스템이 특정 시각에 이상해질 때 원인을 추적하기 쉬움
  • 00:00이 문제된 적은 거의 없었음
    다만 12시간제 시계를 쓰는 환경에서는 혼란이 생길 수 있음

• 시간대 문제를 겪기 전까지는 몰랐는데,
  세상에는 존재하지 않는 시각과 모호한 시각이 있음
  예를 들어 2시에서 3시로 넘어갈 때 2:30은 존재하지 않고,
  반대로 시간을 되돌릴 때는 2:30이 두 번 생김
  국가마다 DST 조정 시각이 달라서, Chile처럼 자정이 사라지는 경우도 있음
  (관련 블로그)
  Java와 Ruby가 이 상황을 다르게 처리해서, Stripe 근무 초기에 3번 연속 사고를 냈던 기억이 있음

• cron 작업은 정각을 피하고, 가능하면 새벽 4시 이후나 자정 이전에 설정함
  공유 인프라에서는 정각에 리소스 경쟁이 심하기 때문임

  • systemd의 RandomizedDelaySec 옵션을 쓰면 충돌을 줄일 수 있음
  • cron 명령 앞에 sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;
    같은 코드를 붙여서 0~59분 랜덤 지연을 주는 것도 좋은 방법임

• 중요한 예약 작업은 가능하면 idempotent(중복 실행 안전) 하게 만들어야 함
  특히 큐 시스템이 얽혀 있을 때 이런 설계가 문제 예방의 핵심임