시간대가 까다로운 주된 이유는 시간에 따라 변화하기 때문입니다. 윤초가 있는 UTC 시계 자체도 복잡하지만, 시간대의 변화는 특정 시점의 시간대 정의가 미래나 과거의 정의와 다를 수 있다는 점에서 더 큰 문제를 야기합니다. 예를 들어, 2011년 모스크바의 일광 절약 시간제(DST) 정책 변경 사례처럼, 이벤트가 예정된 로컬 시간은 동일하더라도 UTC 시간은 변경될 수 있습니다. 이는 알람, 시간 계산, 다른 이벤트와의 정렬 등 모든 관련 작업에 영향을 미칩니다.
이러한 문제를 해결하기 위해서는 ‘시간에 따른 데이터(data-over-time)’ 접근 방식을 따라야 합니다. 이는 특정 로컬 시간에 특정 위치에서 어떤 시간대 규칙이 적용되었는지(또는 적용될 것인지)를 계산하고, 그 정보를 사용하여 로컬 시간을 UTC로 변환하는 것을 의미합니다. 이를 위해 tzinfo 데이터를 포함한 OS, 데이터베이스 서버, Ruby Gem 버전에 이르기까지 전체 스택의 시간대 데이터를 최신 상태로 유지하는 것이 필수적입니다.
반복 이벤트 스케줄링 구현 전략
-
사용자 시간대 정보 확보: 최신 브라우저는
Intl.DateTimeFormat().resolvedOptions().timeZone을 통해 IANA 시간대 식별자(예:America/New_York)를 제공합니다. Rails의time_zone_select가 제공하는 이름(예:Eastern Time (US & Canada))보다는 IANA 식별자를 저장하는 것이 중요하며, 이는TZInfo데이터베이스에서 사용됩니다. -
User 모델에 시간대 저장: Ruby on Rails 애플리케이션에서는
User모델에 IANA 시간대 식별자를 저장하는 커스텀 접근자(time_zone=,time_zone)를 구현하여ActiveSupport::TimeZone객체로 쉽게 변환할 수 있도록 합니다. -
작업 요일 및 시작 시간 정의: 대부분의 경우 월요일부터 금요일까지를 작업 요일로, 오전 9시를 작업 시작 시간으로 설정할 수 있습니다.
-
fugitGem 활용: Ruby 생태계에서 이러한 복잡한 스케줄링을 처리하는 데 이상적인 도구는fugitGem입니다.fugit은 ‘9:00 every Tuesday,Wednesday in America/New_York’와 같은 패턴을 구문 분석하여 다음 발생 시각을 UTC로 정확하게 계산합니다. 이는 시간대 전환이나 DST 전환으로 인해 시간이 사라지는 경우에도 이벤트를 건너뛰는 등 다양한 엣지 케이스를 자동으로 처리합니다.
이러한 접근 방식을 통해 개발자는 시간대 변화로 인한 오류 없이 사용자에게 정확한 시간에 반복 이벤트를 제공할 수 있습니다.