DevUtils
기술 가이드
시간 & 변환기4분 읽기

Unix 타임스탬프와 타임존, ISO 8601 분산 시스템 시간 처리 완벽 가이드

Unix Epoch 정의와 2038년 문제(Y2038), 초 vs 밀리초 단위 버그, 일광절약시간제(DST)의 고려사항, 데이터베이스 UTC 보관 패턴을 명쾌하게 해설합니다.

실시간 온라인 도구 바로가기

Unix 타임스탬프 변환기

서버 전송 없이 100% 브라우저 로컬에서 안전하게 직접 테스트하고 검증해보세요.

도구 실행하기

Unix Epoch 시간이란 무엇이며 왜 글로벌 표준이 되었는가?

Unix 타임스탬프(POSIX 시간)는 Unix Epoch(1970년 1월 1일 목요일 00:00:00 UTC)를 기점으로 경과한 총 초(Second) 수를 나타내는 단일 정수입니다. 분산 환경에서 타임스탬프는 각국 시간대(Timezone)나 서머타임(DST)의 모호함 없이, 단일 스칼라 정수값만으로 시간 선후 관계를 비교하고 정렬할 수 있는 절대적인 기준을 제공합니다.

초(Seconds) vs 밀리초(Milliseconds) 단위 불일치 주의점

다양한 언어를 조합하는 마이크로서비스 환경에서 가장 흔히 발생하는 버그는 시간 단위 불일치입니다:

  • Unix 타임스탬프(초): C, 리눅스 커널, 파이썬 time.time(), Go time.Now().Unix()의 표준 (10자리 정수, 예: 1791000000).
  • 자바스크립트 밀리초(ms): JavaScript의 Date.now()와 Java의 System.currentTimeMillis()는 밀리초(13자리)를 반환합니다. 10자리 초 단위를 자바스크립트 new Date(seconds)에 그대로 넘기면 1970년 1월로 잘못 계산되는 버그가 발생합니다!

프론트엔드와 백엔드 간에 타임스탬프를 주고받을 때는 항상 단위 기준을 명확히 합의해야 합니다.

JAVASCRIPTDevUtils Code Reference
const unixSecondsFromApi = 1791000000;

// ❌ 잘못된 코드: 1,791,000,000 밀리초(1970년 1월 21일)로 해석됨
new Date(unixSecondsFromApi).toISOString(); 

// ✅ 올바른 코드: 1000을 곱해 밀리초 단위로 변환 후 생성
new Date(unixSecondsFromApi * 1000).toISOString();

2038년 문제(Year 2038 Problem, Y2038)의 원인과 현황

부호 있는 32비트 정수(time_t)로 시간을 저장하는 시스템의 최댓값은 2,147,483,647입니다.

2038년 1월 19일 화요일 03:14:07 UTC에 이 최댓값을 초과하는 순간 정수 오버플로가 발생하여 음수로 뒤집히며 1901년으로 시간이 리셋됩니다. 현대 64비트 운영체제와 런타임은 64비트 정수를 사용하여 안전하게 시간을 처리합니다.

웹 애플리케이션 시간대 처리를 위한 실무 권장 원칙

  1. 데이터베이스 저장은 무조건 UTC 기준: PostgreSQL의 TIMESTAMP WITH TIME ZONE 등 항상 UTC를 기준으로 보관해야 합니다.
  2. API 교환 포맷은 ISO 8601 / RFC 3339로 표준화: 통신 규격으로 "2026-10-03T14:30:00.000Z"와 같은 표준 문자열을 사용하세요.
  3. 클라이언트 화면 표시는 브라우저 로컬 변환: 사용자 화면에 보여줄 때만 브라우저의 Intl.DateTimeFormat이나 날짜 라이브러리를 사용하여 사용자의 현지 시간대로 변환합니다.
  4. 오프셋을 하드코딩하지 말 것: 항상 IANA Time Zone 데이터베이스(Asia/Seoul, America/New_York)를 참조하세요.

서머타임(DST) 시계 이동과 윤초(Leap Second) 스미어링의 분산 처리

분산 스케줄러, 크론(Cron) 작업, 백그라운드 워커는 일광절약시간제(DST) 전환 시 치명적인 장애를 겪을 수 있습니다:

  • Spring Forward (1시간 누락): 현지 시각이 01:59:59에서 03:00:00으로 1시간 건너뛸 때, 현지 시각 02:30:00에 예약된 크론 작업은 실행되지 않고 통째로 건너뛰어질 수 있습니다.
  • Fall Back (1시간 반복): 시계가 01:00:00으로 1시간 뒤로 되돌아갈 때, 01:30:00에 예약된 작업이 중복으로 두 번 실행되어 중복 결제나 중복 배치 작업이 발생할 수 있습니다.
  • 아키텍처적 해법: 모든 분산 작업 스케줄러(Temporal, BullMQ, Celery 등)의 트리거 기준은 반드시 현지 시간이 아닌 절대적인 UTC 시간으로 설정해야 합니다.
  • 윤초 스미어링 (Leap Smearing): 지구 자전 속도 변화로 1초를 추가하는 윤초(23:59:60) 발생 시, 시스템 시계가 정지하거나 튀는 문제를 막기 위해 Google, Cloudflare, AWS 등은 24시간에 걸쳐 시계를 밀리초 단위로 천천히 늘려 윤초를 흡수하는 윤초 스미어링 방식을 적용하고 있습니다.
JAVASCRIPTDevUtils Code Reference
// 서머타임 전환에 영향을 받지 않고 두 시점 간의 실제 경과 시간(시간 단위) 계산
function getTrueElapsedHours(startIso, endIso) {
    const startMs = new Date(startIso).getTime(); // 절대적인 단조 UTC 밀리초로 변환
    const endMs = new Date(endIso).getTime();
    return (endMs - startMs) / (1000 * 60 * 60); // 현지 시간대 시계 조작의 영향을 받지 않음
}

// 런던 서머타임 전환일: 2026-03-29 01:00 UTC -> 02:00 BST (하루가 23시간으로 단축되지만 UTC 기준 경과 시간은 정확히 24시간)
console.log(getTrueElapsedHours("2026-03-29T00:00:00Z", "2026-03-30T00:00:00Z")); // 24
태그:유닉스 타임타임존UTCISO 8601분산 시스템
실시간 온라인 도구 바로가기

Unix 타임스탬프 변환기

Unix Epoch 타임스탬프를 UTC 및 현지 날짜시간으로 변환하거나 반대로 계산해주는 무료 온라인 도구.

도구 실행하기