Unix 타임스탬프 설명: 변환과 일반적인 함정

Unix 타임스탬프는 프로그래밍에서 가장 단순하면서도 가장 오해받는 개념 중 하나입니다. 1970년 1월 1일 00:00:00 UTC — Unix 에포크라 불리는 순간부터 경과한 초의 수입니다. 단순함에도 불구하고 타임스탬프는 시간대, 정밀도, 오버플로와 관련된 버그의 원인입니다.

Unix 에포크란?

Unix 에포크 — 1970년 1월 1일, 00:00:00 UTC — 는 Unix 시간의 시작점으로 선택되었습니다. 모든 타임스탬프는 이 순간을 기준으로 측정됩니다:

음수 타임스탬프는 에포크 이전 날짜를 나타냅니다. 예를 들어, -86400은 1969년 12월 31일입니다.

타임스탬프 변환기로 즉시 타임스탬프를 변환하세요.

초 vs. 밀리초

가장 일반적인 혼란 원인입니다. 시스템마다 다른 정밀도를 사용합니다:

경험 법칙: 숫자가 13자리이면 밀리초입니다. 10자리이면 초입니다.

// JavaScript는 밀리초를 반환
const nowMs = Date.now();          // 1700000000000
const nowSec = Math.floor(nowMs / 1000);  // 1700000000

시간대 처리

Unix 타임스탬프는 항상 UTC입니다. 시간대 정보를 포함하지 않습니다. 이것은 사실 장점입니다 — 보편적인 참조점을 제공합니다.

혼란은 타임스탬프를 사람이 읽을 수 있는 날짜로 변환할 때 발생합니다:

const ts = 1700000000;
const date = new Date(ts * 1000);

date.toUTCString();      // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString();    // 사용자의 로컬 시간대에 따라 다름
date.toISOString();       // "2023-11-14T22:13:20.000Z"

모범 사례: 타임스탬프를 UTC로 저장하고 전송하세요. 사용자에게 가능한 가까운 표시 레이어에서만 로컬 시간으로 변환하세요.

2038년 문제

전통적인 Unix 시스템은 타임스탬프를 32비트 부호 있는 정수로 저장합니다. 최대값은 2,147,483,647로, 2038년 1월 19일 03:14:07 UTC에 해당합니다.

이 순간 이후 32비트 타임스탬프는 음수로 오버플로되어 1901년 12월 13일로 돌아갑니다. 이것은 Y2K 버그와 유사합니다.

현재 상태:

• 대부분의 현대 시스템은 64비트 타임스탬프 사용 (2920억 년까지 유효)
• Linux 커널은 버전 5.6 (2020)부터 64비트 타임스탬프 클린
• 임베디드 시스템과 레거시 데이터베이스는 여전히 위험
• 2038년 이후 날짜를 처리하는 소프트웨어를 구축한다면 타임스탬프 저장을 확인하세요

다양한 언어에서의 변환

JavaScript

// 현재 타임스탬프 (초)
const now = Math.floor(Date.now() / 1000);

// 타임스탬프에서 Date로
const date = new Date(1700000000 * 1000);

// Date에서 타임스탬프로
const ts = Math.floor(new Date('2023-11-14').getTime() / 1000);

Python

import time, datetime

# 현재 타임스탬프
now = int(time.time())

# 타임스탬프에서 datetime으로
dt = datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)

# datetime에서 타임스탬프로
ts = int(dt.timestamp())

SQL (PostgreSQL)

-- 현재 타임스탬프
SELECT EXTRACT(EPOCH FROM NOW());

-- 타임스탬프에서 날짜로
SELECT TO_TIMESTAMP(1700000000);

-- 날짜에서 타임스탬프로
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);

일반적인 함정

1. 초와 밀리초 혼합

날짜가 1970년 1월로 표시되면, 밀리초가 예상되는 곳에 초를 전달했거나 (또는 반대) 한 것입니다. 항상 API가 어떤 정밀도를 예상하는지 확인하세요.

2. 날짜 문자열에서 시간대 무시

시간대 없이 "2023-11-14"를 파싱하면 로컬 시간대에서 날짜를 생성하며, 이는 서버 위치에 따라 달라집니다. 항상 시간대를 포함하세요: "2023-11-14T00:00:00Z".

3. 부동소수점 정밀도

타임스탬프를 부동소수점 숫자로 저장하면 밀리초 이상에서 정밀도를 잃을 수 있습니다. 마이크로초나 나노초 정밀도에는 적절한 승수를 가진 정수를 사용하세요.

4. 윤초

Unix 타임스탬프는 윤초를 반영하지 않습니다. Unix 일은 실제 UTC 일이 간혹 86,401초를 가져도 항상 정확히 86,400초입니다. 대부분의 애플리케이션에서 이것은 무관합니다. 과학이나 위성 애플리케이션에는 TAI (국제 원자 시간)를 사용하세요.

ISO 8601: 사람이 읽을 수 있는 대안

타임스탬프가 계산에 좋지만, ISO 8601은 사람이 읽을 수 있는 날짜 표현의 표준입니다:

2023-11-14T22:13:20Z          # UTC
2023-11-14T17:13:20-05:00     # 동부 시간
2023-11-14                     # 날짜만

대부분의 API는 ISO 8601 문자열을 수용하고 반환해야 합니다. 계산과 저장에는 내부적으로 타임스탬프를 사용하세요.

FAQ

Unix 시간은 왜 1970년 1월 1일에 시작하나요?

이 날짜는 1970년대 초 Bell Labs에서 Unix가 개발될 때 임의로 선택되었습니다. 먼 과거 날짜에 비트를 낭비하지 않기 위해 충분히 최근 날짜가 필요했습니다. 32비트 정수는 각 방향으로 약 68년을 저장할 수 있으므로, 1970에서 시작하면 1901부터 2038까지의 날짜를 커버합니다.

데이터베이스에 날짜를 타임스탬프로 저장해야 하나요, 포맷된 문자열로 저장해야 하나요?

효율적인 정렬, 비교, 산술을 위해 타임스탬프 (정수 또는 네이티브 datetime 유형)로 저장하세요. 포맷된 문자열은 쿼리와 정렬이 올바르게 더 어렵습니다. 대부분의 데이터베이스에는 이를 잘 처리하는 네이티브 datetime 유형이 있습니다. 문자열 포맷팅은 표시와 API 응답에만 사용하세요.

관련 리소스

• 타임스탬프 변환기 — Unix 타임스탬프와 사람이 읽을 수 있는 날짜 간 변환
• JSON 포맷팅 모범 사례 — JSON 응답에서 날짜 처리
• UUID 가이드 — 시간 기반 변형이 있는 또 다른 일반적인 식별자 포맷