퀴즈: 타임존·영업일·마감시각

이체 접수 시각을 DB 에 남길 때 가장 알맞은 방식은?

• 접수 순간을 UTC 로, 오프셋이 붙은 RFC 3339 문자열로 남기고 날짜는 읽을 때 계산한다
• 업무가 쓰는 KST 지역시각을 오프셋 없이 남기고 필요할 때 9시간을 뺀다
• 접수 날짜(YYYY-MM-DD)만 남기고 시각은 별도 열에 문자열로 남긴다
• 서버의 지역시각을 그대로 남기고 서버 TZ 설정을 문서에 적어 둔다

마감시각 16:30(KST) 규칙을 received_utc[11:16] >= "16:30" 으로 구현했다. 이 코드의 문제는?

• 문자열 비교라서 시각의 대소가 뒤집혀 정각 경계가 반대로 판정된다
• UTC 시각을 지역시각으로 옮기지 않고 비교해서 마감 기준이 9시간 어긋난다
• 초 단위가 빠져 있어 마감 정각의 1초 전후를 구분하지 못한다
• received_utc 가 문자열이라 인덱스를 못 타서 집계가 느려진다

Asia/Seoul 을 고정 UTC+9 로 구현한 코드가 1987년 7월의 이관 데이터를 읽을 때 생기는 일은?

• 연도가 tzdb 의 수록 범위 밖이라 변환이 예외로 떨어진다
• 그 시기 자료에는 시간대 정보가 없어 결과가 실행할 때마다 달라진다
• 그때는 서머타임으로 UTC+10 이었으므로 한 시간 일찍 읽히고 자정 근처는 날짜가 하루 어긋난다
• 오프셋은 같지만 표기가 KST 대신 KDT 라서 문자열 비교만 틀어진다

휴장일 달력을 어디에 두는 것이 가장 알맞은가?

• 엔진 코드의 상수 목록에 둔다. 배포로 관리되니 변경 이력이 남는다
• 운영체제의 시간대 데이터에 들어 있으므로 zoneinfo 에서 읽어 쓴다
• 영업일 판정이 필요한 서비스마다 각자 목록을 두고 주기적으로 맞춘다
• DB 표에 두고 엔진이 실행할 때 읽는다. 기관과 해마다 다르기 때문이다

접수 순간이 2026-07-02T07:30:00Z 이고 마감시각이 16:30(KST), 다음 날 7월 3일이 영업일일 때 결제일은?

• 2026-07-02 — KST 로 16:30 정각이지만 경계는 초과할 때만 넘긴다
• 2026-07-03 — KST 로 16:30 정각이라 마감에 걸려 다음 영업일이 된다
• 2026-07-02 — UTC 로는 아직 07:30 이라 마감 전이다
• 2026-07-06 — 마감을 넘겼으므로 다음 주 첫 영업일로 민다

결제일 규칙이 바뀌어 전 건을 다시 계산해야 한다. 원장 설계로 가장 알맞은 것은?

• 원장의 결제일 열을 새 값으로 UPDATE 하고 변경 시각을 같은 행에 적는다
• 옛 결제일로 계산된 행만 골라 지우고 새 규칙으로 다시 적재한다
• 결제일 열을 두 개로 늘려 옛 값과 새 값을 한 행에 나란히 둔다
• 원장을 그대로 두고 재계산 결과를 별도 표에 규칙 정보와 함께 넣는다