Unix 타임스탬프가 뭐고 왜 신경 써야 해?

API 응답을 디버깅하고 있어. created_at이라는 필드에 1704067200 값이 있어. 무슨 날이야?

그게 Unix 타임스탬프야. 1970년 1월 1일 이후의 초 수야. 이해하면 어디서나 볼 거야.

왜 1970년?

Unix는 1960년대 후반에 개발되고 있었어. 설계자들이 시간 계산을 위한 시작점이 필요했어. 1970년 1월 1일이 실용적일 만큼 최근이고, 대부분의 컴퓨팅 역사를 커버할 만큼 이르렀어.

그 순간—1970년 1월 1일 UTC 자정—이 Unix epoch라고 불려.

왜 날짜 대신 초?

날짜는 복잡해. 타임존, 서머타임, 윤년, 다양한 월 길이. "2024년 3월 15일 오후 3시 EST"는 많은 파싱이 필요해.

타임스탬프는 그냥 숫자야. 1710522000. 저장하기 쉽고, 비교하기 쉽고, 수학하기 쉬워.

어느 이벤트가 먼저 일어났는지 알고 싶어? 두 숫자를 비교해. 뭔가 얼마나 걸렸는지? 타임스탬프 빼. 24시간 더하고 싶어? 86400 더해.

타임존 장점

영리한 부분이 여기야: 타임스탬프는 항상 UTC야.

도쿄의 누군가와 뉴욕의 누군가가 둘 다 같은 순간을 기록하면 같은 타임스탬프를 받아. 표시는 다를 수 있어—하나는 오전 9시를 보고, 다른 하나는 오후 7시—하지만 기본 숫자는 동일해.

이게 분산 시스템을 가능하게 만들어. 데이터베이스, API, 로그 파일—모두 서버가 어디 있든 같은 기준점을 써.

밀리초 vs 초

JavaScript는 epoch 이후 밀리초를 써. 대부분의 다른 언어는 초를 써.

1704067200 (초) = 2024년 1월 1일, 00:00:00 UTC 1704067200000 (밀리초) = 같은 순간

타임스탬프가 너무 커 보이면 아마 밀리초야. 1000으로 나눠.

타임스탬프 빨리 읽기

정신 수학을 보정할 몇 가지 기준점:

• 1000000000 (10억) = 2001년 9월 9일
• 1600000000 = 2020년 9월
• 1700000000 = 2023년 11월
• 1800000000 = 2027년 1월

현재 타임스탬프는 17억 범위야. 17로 시작하는 걸 보면 아마 최근 타임스탬프야.

흔한 작업

현재 타임스탬프:

Math.floor(Date.now() / 1000)  // JavaScript

import time; int(time.time())  # Python

타임스탬프를 날짜로:

new Date(1704067200 * 1000)  // JavaScript는 밀리초 필요

날짜를 타임스탬프로:

Math.floor(new Date('2024-01-01').getTime() / 1000)

2038년 문제

Unix 타임스탬프는 원래 32비트 부호 있는 정수로 저장됐어. 최대값? 2,147,483,647.

그게 2038년 1월 19일, 03:14:07 UTC야.

그 순간 이후 32비트 시스템은 오버플로우할 거야. 타임스탬프용 Y2K야.

대부분의 현대 시스템은 이제 64비트 정수를 써서 수십억 년 동안 오버플로우 안 해. 하지만 레거시 시스템이 존재해. 오래된 코드로 작업하면 확인할 가치가 있어.

타임스탬프가 이상해질 때

음수 타임스탬프. 1970년 전 날짜는 음수야. -86400은 1969년 12월 31일.

윤초. UTC는 가끔 지구 자전과 동기화를 유지하려고 초를 추가해. 대부분의 시스템이 이걸 무시해. 가끔 혼돈을 일으켜.

클럭 드리프트. 서버 시계가 동의하지 않을 수 있어. 다른 머신의 두 타임스탬프가 시계가 동기화되지 않았으면 직접 비교 가능하지 않을 수 있어.

---

타임스탬프는 찾기 시작하면 어디든 있어. API 응답, 데이터베이스 레코드, 로그 파일, 쿠키. 이해하면 디버깅이 더 빨라지고 시간 관련 코드가 덜 신비로워져.