유닉스 시간표 설명: 초, 밀리 초, 시간대 및 2038

거의 모든 로그 파일, 데이터베이스 테이블 또는 API 응답을 열면 1760000000 같은 숫자를 찾을 수 있습니다. 이것은 유닉스 시간표입니다. 1970년 1월 1일 00:00:00 UTC 이후의 초 수를 유닉스 시대라고 합니다. 이것은 컴퓨터가 시간적 순간을 표현하는 가장 일반적인 방법이고, 그것을 이해하는 것은 시간대, 여름철, 날짜 분석 등과 관련된 모든 종류의 버그를 방지합니다.

왜 1970년부터 초를 세는 거야?

초기 유닉스 개발자들은 단순하고 컴팩트한 시간의 표현이 필요했습니다. 고정된 최근 날짜에서 세컨드를 계산하는 것은 하나의 정수에 맞게 비교하고 빼는 것이 쉬웠고 달력의 복잡성을 피했습니다. 1970년 1월 1일은 유닉스가 만들어지고 있을 때 매우 편리한 출발점이었습니다.

그 장점은 오늘날에도 유효합니다.

• ** 시간대 독립적. * * 시간표는 벽 시계 읽기가 아닌 순간을 식별합니다. 동일 이벤트 도쿄, 베를린과 상파울루에서 동일한 시간표가 있습니다.
• ** 쉬운 수학적 계산이다. * * 두 개의 시간표 사이의 차이는 수초의 시간이다. 하루 동안 86,400개의 움직임을 더합니다.
• ** 컴팩트하고 정렬 가능합니다.** 정수에는 8바이트가 소요되며 시간 순으로 정렬됩니다.
• 무명하다. 03/04가 3월 4일이나 4월 3일인 것을 의미한다는 것을 혼동할 수 없습니다.

초 대 밀리 초

가장 흔한 시간표 오류는 단위 혼합입니다:

• 유닉스 도구, 대부분의 데이터베이스, JWT 및 많은 API는 오늘날 1760000000과 같이 10자리인 초를 사용합니다.
• 자바스크립트의 Date.now(), 자바의 System.currentTimeMillis()와 많은 분석 시스템은 밀리초: 1760000000000와 같은 13자리입니다.
• 일부 시스템은 마이크로초 (16자리) 또는 나노초 (19자리) 를 사용합니다.

밀리초를 초로 해석하면 수십만 년 후의 날짜가 나옵니다. 역으로 보면 1970년 1월에 도착합니다. 만약 여러분이 UI에서 "1970-01-21"를 본다면, 누군가가 밀리초가 예상되는 곳에서 초를 통과했습니다. [시간표 변환기] ((/ 도구/시간표) 는 단위를 길이를 기준으로 감지합니다. 이는 빠른 정신 검증입니다.

통용 언어로 시간표를 변환

자바스크립트

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

파이썬

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

파이썬에서 항상 tz=을 전달합니다. 그렇지 않으면 fromtimestamp는 오해하기 쉬운 순진한 현지 시간을 반환합니다.

**SQL (PostgreSQL) **

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

가자

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

시간대: UTC를 저장, 지역 표시

시간표는 시간대가 없고 절대적인 순간입니다. 사람이 읽을 수 있는 날짜로 변환할 때 문제가 발생합니다.

• ** new Date("2026-03-29 02:30")은 코드를 실행하는 기계의 로컬 시간대에 해석됩니다. UTC에서 서버와 베를린에서 노트북에서 서로 다른 시간표를 생성합니다.
• 낮을 절약하는 시간 간격과 중복. DST가 적용되는 지역에서는 일부 지역 시간은 존재하지 않습니다 (시계가 앞쪽으로 뛰고) 다른 일부는 두 번 발생합니다 (시계가 뒤로 이동합니다). 시간표에는 그런 모호함이 없습니다.
• 지역 시간을 저장합니다. "2026-11-01 01:30"를 구역 없이 저장하면 어느 순간인지 절대 알 수 없습니다.

엄지 손가락 규칙: 시간표 또는 ISO 8601 문자열을 명시적인 오프셋 (2026-10-11T09:30:00Z 또는 +02:00) 으로 저장하고 전송합니다. 표시할 때만 사용자 로컬 영역으로 변환합니다. 사용자의 IANA 시간대 이름 (Europe/Berlin와 같이) 을 별도로 저장합니다.

ISO 8601 대 유닉스 시간표

2026-10-11T09:30:00Z과 같은 ISO 8601 문자열은 Z 또는 오프셋을 포함할 때 인간으로 읽을 수 있으며 명확합니다. 많은 API는 가독성을 위해 그들을 선호합니다. 유닉스 타임 스탬프는 작고 비교가 빨라요. 둘 다 괜찮습니다. 중요한 것은 일관성이고 항상 구역 정보를 포함하는 것입니다.

스키스트 초

지구의 자전은 약간 불규칙하기 때문에 공식 UTC는 때때로 오차 초를 삽입합니다. 유닉스 시계는 그것들을 무시합니다. 매일은 정확히 86,400초이고, 초과초 동안 시간표가 반복되거나 지워집니다. 거의 모든 애플리케이션에서 이것은 보이지 않습니다. 고정밀 시계를 사용한다면 TAI 또는 GPS 시간을 사용하세요. 국제 시간 측정 기관들은 2035년까지 점진 초를 점차적으로 폐지하기로 결정했습니다.

2038년 문제

많은 오래된 시스템에서는 유닉스 시간을 서명된 32비트 정수로 저장하며, 최대 값은 2,147,483,647이다. 2038년 1월 19일 UTC 03:14:07에 해당됩니다. 1초 후, 값은 -2,147,483,648로 넘쳐나고, 이는 1901년 12월 13일을 나타냅니다.

현대 64비트 운영 체제, 언어 및 데이터베이스는 약 2920억 년 동안 넘지 않는 64비트 타임 스탬프를 사용합니다. 위험은 다음과 같습니다.

• 내장장장치와 산업용 컨트롤러
• 파일 형식과 32비트 시간 필드를 가진 네트워크 프로토콜
• 32비트 INT로 선언된 데이터베이스 열, 에포크 초를 보유합니다. MySQL의 TIMESTAMP 타입은 2038의 한계를 가지고 있으며, DATETIME 또는 BIGINT는 그렇지 않습니다.

이제 장기적인 데이터를 감사하세요. 특히 인증서 만료나 20년 계약 같은 미래 날짜를 저장하는 모든 것을요.

부정적 시간표

1970년 이전 날짜는 시간표가 부정적이죠. -86400은 1969년 12월 31일입니다. 대부분의 현대 언어는 그것들을 올바르게 처리하지만, 일부 오래된 API와 스프레드시트는 그렇지 않습니다. 따라서 역사적 날짜를 명시적으로 테스트하십시오.

실제 디버깅 체크리스트

1. 숫자를 세어 보세요. 10은 초, 13은 밀리 초입니다.
2. 먼저 UTC로 전환하고, 지역 시간으로 전환하여, 단위 버그와 구역 버그를 분리합니다.
3. 날짜 문자열이 Z 또는 오프셋을 포함하는지 확인합니다.
4. 토큰이나 서명이 실패하면 서버와 클라이언트 클럭을 비교합니다. "시효가 경과" 또는 "아직 유효하지 않습니다". 오류가 발생하면 exp과 nbf가 유닉스 초인 이유에 대해 [JWT 작동 방식] (/blog/how-jwt-works) 를 참조하십시오.
5. 반복되는 작업을 스케줄링할 때, 크론이 서버의 영역에서 실행된다는 것을 기억하십시오. [이 크론 예제] (/blog/cron-expression-examples) 는 세부 사항을 다루고 있습니다.

요약

유닉스 타임 스탬프는 1970-01-01 UTC 이후의 초 수입니다. 그것은 간단하고 시간대 독립적이며 계산하기 쉽습니다. 대부분의 버그는 초와 밀리 초를 섞거나 지역 없이 날짜를 분석하거나 지역 시간을 저장하는 것에서 발생합니다. UTC를 저장하고, 가장자리에 변환하고, 64비트 정수를 사용하면