LabHub
배우기 러닝패스 코스

로그가 미래에서 왔다 — 시계가 만든 다섯 사건 · 새벽 한 시가 두 번 왔다 · 퀴즈

퀴즈: 새벽 한 시가 두 번 왔다

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 그 한 시간의 지역 시각이 두 번 나타나 같은 값이 서로 다른 두 순간을 가리킨다
    2. 그 한 시간의 기록이 모두 한 시간 뒤로 옮겨져 저장된다
    3. 그 한 시간의 지역 시각이 사라져 해당 기록이 하나도 남지 않는다
    4. 그 한 시간 동안만 오프셋이 기록에 함께 저장되어 구분이 가능해진다
  2. 파이썬에서 지역 시각 하나가 「두 번 오는 시각」인지 「없는 시각」인지 가르는 방법은?

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

    1. 입력된 시간대 이름을 값과 함께 저장해 두었다가 읽을 때 그대로 돌려준다
    2. 입력을 UTC 로 바꿔 저장하고 읽을 때 세션의 시간대로 보여 준다
    3. 적힌 숫자를 그대로 들고 있다가 읽을 때도 그대로 돌려준다
    4. 서버의 지역 시각으로 바꿔 저장하고 읽을 때도 그 지역 시각으로 돌려준다
  4. 「저장은 UTC 로」 라는 규칙에 두어야 할 예외는?

    1. 초 이하 정밀도가 필요한 고빈도 거래 기록
    2. 법적으로 보존 기간이 정해진 감사 로그
    3. 여러 지역에서 동시에 읽는 대시보드의 집계 결과
    4. 미래의 지역 시각으로 한 약속, 예를 들어 다음 달 현지 오전 9시 회의
  5. 시간대 오프셋을 코드에 +09:00 처럼 숫자로 박아 두면 안 되는 이유는?

    1. 지역 시각 규칙은 정치적 결정으로 계속 바뀌므로 이름으로 저장하고 변환을 데이터베이스에 맡겨야 한다
    2. 오프셋 숫자는 초 단위 정밀도가 없어 일부 지역을 표현하지 못하기 때문이다
    3. 오프셋을 숫자로 쓰면 RFC 3339 형식을 만족하지 못하기 때문이다
    4. 대부분의 언어가 오프셋 숫자를 문자열로만 다뤄 비교가 느려지기 때문이다
  6. 서머타임이 시작되는 새벽의 없는 시각에 걸린 예약 작업이 특히 늦게 발견되는 이유는?

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