정해진 지역 시각에 자동 작업을 실행하는 예약 스케줄러에는 서로 다른 세 개의 시계가 있다. 반복 규칙을 적은 cron 식, 시스템이 저장한 다음 실행 시각, 운영자가 실제로 보는 지역 시각이다. 셋 가운데 하나라도 어긋나면 규칙이 멀쩡해 보여도 작업은 엉뚱한 때에 시작된다.
아침 글 발행 작업의 cron 식은 매일 10시 17분을 가리켰다. 하지만 실행 기록은 없었고 시스템이 예고한 다음 실행은 저녁 7시 17분이었다. 첫 번째 시계만 보고서는 이상을 찾을 수 없는 상태였다.
저장값을 비교하자 차이가 드러났다. 이전 값은 2026-09-02T10:17:00+09:00, 이후 값은 2026-09-02T10:17:00+00:00이었다. 10:17은 같아도 두 값은 같은 순간이 아니다. 뒤의 오프셋이 UTC로 바뀐 두 번째 값은 한국에서 저녁 7시 17분이다.
이 문제는 한 작업만 다시 켠다고 닫히지 않는다. 전체 18개 작업에 대해 cron 식으로 기대되는 다음 실행을 계산하고, 저장값을 한국 시각으로 변환해 한 줄씩 맞췄다. 대부분은 이미 정상화됐지만 아침 발행과 주기적 검토 작업의 다음 실행은 여전히 틀려 있었다. 오후 발행 작업 하나는 저장 오류와 별개로 과거 일정이 현재 운영 기준과 달랐다.
승인된 네 일정만 명령행 도구로 다시 등록했다. 작업 내용은 건드리지 않았고 스케줄러 서비스도 재시작하지 않았다. 수정 뒤 같은 18개 행을 다시 계산하자 불일치는 0이 됐다.
공용 로그에는 시간대 오프셋이 바뀐 사실이 남아 있지만, 어느 프로세스가 그 수정을 실행했는지는 확정할 수 없었다. 그래서 원인 이름을 붙이는 대신 세 시계를 함께 검사하는 기준을 남겼다. cron 식, 저장된 다음 순간, 지역 시각 변환값이 모두 맞아야 예약 작업이 복구됐다고 말할 수 있다.