クイズ：午前一時が二度来た

지역 시각으로 저장한 기록에서 서머타임이 끝나는 날 새벽에 벌어지는 일은?

• 그 한 시간의 지역 시각이 두 번 나타나 같은 값이 서로 다른 두 순간을 가리킨다
• 그 한 시간의 기록이 모두 한 시간 뒤로 옮겨져 저장된다
• 그 한 시간의 지역 시각이 사라져 해당 기록이 하나도 남지 않는다
• 그 한 시간 동안만 오프셋이 기록에 함께 저장되어 구분이 가능해진다

파이썬에서 지역 시각 하나가 「두 번 오는 시각」인지 「없는 시각」인지 가르는 방법은?

• fold 를 0 과 1 로 두었을 때 오프셋이 달라지는지만 보면 된다
• 그 시각이 속한 날에 전환이 있었는지를 시간대 이름에서 읽어 낸다
• fold=0 으로 UTC 에 갔다가 되돌아왔을 때 원래 값이 나오는지로 가른다
• utcoffset() 이 None 을 돌려주는지로 가른다

PostgreSQL 의 timestamptz 형이 실제로 하는 일은?

• 입력된 시간대 이름을 값과 함께 저장해 두었다가 읽을 때 그대로 돌려준다
• 입력을 UTC 로 바꿔 저장하고 읽을 때 세션의 시간대로 보여 준다
• 적힌 숫자를 그대로 들고 있다가 읽을 때도 그대로 돌려준다
• 서버의 지역 시각으로 바꿔 저장하고 읽을 때도 그 지역 시각으로 돌려준다

「저장은 UTC 로」 라는 규칙에 두어야 할 예외는?

• 초 이하 정밀도가 필요한 고빈도 거래 기록
• 법적으로 보존 기간이 정해진 감사 로그
• 여러 지역에서 동시에 읽는 대시보드의 집계 결과
• 미래의 지역 시각으로 한 약속, 예를 들어 다음 달 현지 오전 9시 회의

시간대 오프셋을 코드에 +09:00 처럼 숫자로 박아 두면 안 되는 이유는?

• 지역 시각 규칙은 정치적 결정으로 계속 바뀌므로 이름으로 저장하고 변환을 데이터베이스에 맡겨야 한다
• 오프셋 숫자는 초 단위 정밀도가 없어 일부 지역을 표현하지 못하기 때문이다
• 오프셋을 숫자로 쓰면 RFC 3339 형식을 만족하지 못하기 때문이다
• 대부분의 언어가 오프셋 숫자를 문자열로만 다뤄 비교가 느려지기 때문이다

서머타임이 시작되는 새벽의 없는 시각에 걸린 예약 작업이 특히 늦게 발견되는 이유는?

• 실행은 됐지만 결과 파일이 다른 날짜 디렉터리에 쌓이기 때문이다
• 실행이 실패한 것이 아니라 아예 일어나지 않아 실패 알림도 오지 않기 때문이다
• 그 시각의 로그만 시간대 변환 과정에서 버려지기 때문이다
• 스케줄러가 다음 날로 미뤄 두었다가 조용히 실행하기 때문이다