2026-08-06 05:49 UTC 에, 미국 종목은 2026-08-05 소속이었고 도쿄 종목은 2026-08-06 소속이었다. 어느 쪽도 오래되지 않았고, 어느 쪽도 틀리지 않았다.
논쟁을 끝내는 관측
시간대 버그는 긴 토론을 낳아. 참여자마다 머릿속 모형이 있고 모형이 전부 국소적으로는 일관되거든. 토론은 누가 측정값을 내놓을 때 끝나고, 이게 그 측정값이야. 종목 둘, 한 순간에 조회, 서로 다른 장 날짜 둘. 둘 다 맞음.
이 사실 하나가 오프셋에 대한 어떤 추론보다 일을 많이 해. '오늘' 이 프로세스의 성질이 아니라는 걸 증명하거든. 종목마다의 성질이고, 프로세스가 참조할 수 있는 시계 중에 — 로컬도, UTC 도, 어느 거래소 것도 — 전부에 대해 동시에 맞는 건 없어.
그러니까 수선의 모양이 강제돼. 더 나은 전역 날짜도 아니고, 더 똑똑한 오프셋 테이블도 아니고, 행마다 붙는 날짜. 그 행 자기 종목에서 뽑아낸.
추론이 못 끝내는 설계 논쟁을 측정이 끝내. 사람 둘이 양립 불가능한 시간대 모형을 무기한 붙들 수 있어. 각자 자기가 떠올린 예시 안에서는 각 모형이 잘 돌아가니까. 서로 다른 정답 둘을 보여주는 포착된 한 순간은 반박이 안 돼. 그리고 그걸 만드는 비용은 API 호출 두 번이었고.
이 수선이 영구히 배제하는 것
결과를 천천히 읽어봐. "날짜 버그를 고쳤다" 보다 센 얘기니까.
- 실행 단위 날짜 없음. 그 날짜를 아무리 조심해서 뽑아도 패스가 자기 날짜를 뭐에도 찍을 수 없어.
- 기준 시장 하나 없음. "전부 뉴욕 날짜로" 는 세 시장 중 둘한테 틀려.
- UTC 를 진실로 삼기 없음. UTC 는 모호하지 않은데, 사람들이 그걸 맞다는 걸로 착각해. 근데 UTC 달력으로 거래하는 거래소는 없으니까 UTC 날짜는 그냥 네 번째 오답이야.
- "이 정도면 됐지" 없음. 07:11 Asia/Seoul 에서 이 불일치는 자정 근처에서 터지는 예외 사례가 아니야. 매 실행의 정상 상태야.
일반형: 배치의 사실이냐 항목의 사실이냐
이건 시장을 훨씬 넘어서 일반화돼. 서로 다른 맥락의 항목을 건드리는 배치라면 다 같은 질문을 만나. 어떤 사실이 배치 것이고 어떤 사실이 항목 것인가?
배치가 정당하게 소유하는 것: 언제 돌았나, 어느 버전 코드가 돌렸나, 얼마나 걸렸나, 항목 몇 개를 처리했나. 항목이 소유하는 것: 뭐에 관한 건가, 그 대상이 언제 일어났나, 어느 권위가 그걸 정의하나, 단위가 뭔가. 버그는 항상 같은 모양이야. 항목 것인 사실이 배치에서 찍혀. 코드를 쓰는 순간에는 마침 항목 맥락이 하나뿐이었고 그래서 그 구분이 안 보였으니까.
시장이 하나였으면 안 보였을 이유. 미국 전용 판이었으면 똑같이 결함 있는 줄을 갖고도 틀린 행을 한 번도 안 냈을 거야. 루프 시각을 그 하나의 시장에 맞춰 골랐을 테니까. 버그를 표현 가능하게 만든 건 두 번째 시장이고, 덮을 수 없게 만든 건 세 번째야. 시스템은 보통 이 부류 결함을 아직 그게 문제가 안 될 만큼 작을 때 얻고 — 그다음 계속 갖고 가.