Unix 타임스탬프 변환기: Epochs, Timezones 및 Year-57123 버그

내 Laravel SaaS 앱 중 하나의 사용자가 한 번 이메일을 보내 구독 갱신 날짜가 "a bit generous." 청구 페이지가 그에게 그의 계획이 4 월 25 일에 갱신 될 것이라고 말했습니다 57123.

모든 개별 조각이 정확했기 때문에 버그를 찾는 데 당황스러울 정도로 오랜 시간이 걸렸습니다. React 프런트엔드가 전송되었습니다 Date.now()- 돌아옵니다 밀리초- PHP 백엔드가 그랬습니다 date('Y-m-d', $timestamp), 예상합니다 초. 먹이 1740470400000 기대하는 함수로 1740470400 그리고 당신은 대략 55,000 년 후의 미래에 착륙합니다. 예외도 없고,경고도 없고,실패한 테스트도 없습니다. 단지 고객이 정중하게 그의 구독이 문명의 열사망까지 정말로 지속되었는지 물어보는 것입니다.

타임스탬프는 소프트웨어에서 가장 지루한 주제처럼 보입니다. They're 는 실제로 우리가 가지고 있는 가장 신뢰할 수 있는 버그 공장 중 하나입니다: 초 대 밀리초,UTC 대 로컬,DST 전환,2038 롤오버. The 타임스탬프 변환기 on Toolz.dev 는 내가 하는 것에 지쳐서 존재한다 new Date(x * 1000) 브라우저 콘솔에서 하루에 마흔 번. 이 가이드는 내가 지금 확인하는 것을 내가 확인하는 순서대로 다룬다.

TL;DR: Unix 타임스탬프는 1970-01-01T00:00:00 UTC 이후 초를 계산합니다. 10 자리 = 초, 13 자리 = 밀리초- 그들을 섞으면 날짜가 55,000 년이나 쉰다. UTC 저장, 디스플레이 전용 변환, IANA 구역 이름 같은 것을 사용하세요 Asia/Dhaka 약어 대신. 아무 타임스탬프나 the 에 붙여넣습니다 타임스탬프 변환기 ISO 8601, RFC 2822, 로컬 및 UTC 양식을 얻으려면 클라이언트 측에서 실행되므로 타임스탬프가 제거됩니다 JWT 그리고 생산 로그는 브라우저를 떠나지 않습니다.

Unix 타임스탬프란 정확히 무엇입니까?

유닉스 타임스탬프 (epoch time,POSIX time) 는 그 이후 경과된 초의 수이다 1970년 1월 1일 00:00:00 UTC- the "Unix epoch." It's 는 단일 정수이며,시간대가 없으며 (it's 는 정의에 따라 항상 UTC), 효과적으로 모든 OS,언어 및 데이터베이스가 그것을 이해합니다. 그 마지막 속성은 그것이 50 년 동안 살아남은 이유입니다: 아무도 논쟁하지 않는 일회성 형식입니다.

왜 1970 년인가? 깊은 이유는 없다 - 유닉스가 벨 연구소에서 만들어질 때 가까운 편리한 라운드 데이트였고,초기 유닉스는 32 비트 정수로 시간을 세었다. 임의적인 선택은 보편적인 표준으로 화석화되었는데,그것은 매우 유닉스이다.

눈에 보이는 대로 인식할 가치가 있는 몇 가지 기준점:

그 네 번째 행은 미묘한 이유에 대한 내가 좋아하는 예입니다: 튜토리얼 페이지 목록이 많이 1740470400 &quot로서;2025년 2월 25일 12:00:00." It's 실제로 08:00 UTC- 누군가가 자신의 지역 timezone 에서 한 번 변환하고 잘못된 값이 그 이후로 주위에 복사 붙여 넣기되었습니다. 블로그 게시물이 아닌 도구로 타임스탬프를 확인합니다. 이 하나를 포함하여.

초 또는 밀리초 - 어떻게 말합니까?

숫자를 세어보세요. 현재 시대의 모든 날짜에 대해:

• 10자리 (1740470400) - 초. 유닉스 컨벤션,대부분의 API,PHP's time(), 파이썬's time.time() (부유물로서), Stripe's API.
• 13자리 (1740470400000) - 밀리초. 자바스크립트's Date.now(), 자바's System.currentTimeMillis(), MongoDB 날짜.

이것은 내 년-57123 갱신 날짜를 생산 하는 정확한 구별, 그래서 I'll 실패 모드를 철자:

• ms는 초 → 날짜 ~55,000년으로 해석됩니다 미래
• 초는 ms → 날짜로 해석됩니다 1970년 1월 (모든 것이 시대로부터 ~3주 이내로 무너집니다.)

서명 중 하나를 볼 경우 - 고대 날짜 또는 터무니 먼 미래 날짜 - 당신은 코드의 라인을 읽기 전에 버그를 알고. 그만큼 타임스탬프 변환기 숫자 수를 감지하고 두 해석에 레이블을 지정하여 "is this s or ms?" 인수를 2초 안에 완료합니다.

실제로 알아야 할 날짜 형식은 무엇입니까?

세 가지는 작업 개발자가 만지는 거의 모든 것을 다룹니다.

ISO 8601- 국제 표준 및 API 및 로그에서 방출해야 하는 내용:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

아무도 언급하지 않는 킬러 기능: ISO 8601 문자열 사전순으로 시간순으로 정렬합니다. sort 로그 파일에서는 그냥 작동합니다. 02/25/2026-스타일 형식 can't 그렇게 할 수 있습니다. 더 나쁜 것은 미국입니다 MM/DD 그리고 유럽인 DD/MM 매달 12일 동안은 구별할 수 없습니다.

RFC 3339 (스펙) - ISO 8601의 인터넷 프로토콜 프로필입니다. 약간 더 엄격함; API가 방출되는 경우 2026-07-13T09:30:45Z 둘 다 만족합니다. 표준화할 형식입니다.

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - 이메일과 HTTP 헤더,RSS 피드. 당신은 당신이 그것을 작성하는 것보다 더 자주 읽습니다.

데이터베이스 형식은 가까운 사촌입니다: MySQL DATETIME 이다 2026-07-13 09:30:45 (공백이 있는 ISO), PostgreSQL timestamptz 렌더링 2026-07-13 09:30:45+00.

내가 사용하는 언어는 타임스탬프를 어떻게 처리합니까?

내 스택의 세 가지와 개인적으로 시간이 많이 걸리는 각각의 특이한 점.

자바스크립트 (ms one):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

Quirk: 모든 것이 밀리초이고 new Date(1740470400) 묵묵히 2025 년 2 월 대신 1970 년 1 월 21 일을 제공합니다. 오류 없음. 이 비대칭성은 웹 개발에서 가장 일반적인 단일 타임스탬프 버그입니다.

PHP (초):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

퀴크: date() 형식 서버's 기본 시간대이므로 동일한 코드가 기계와 생산에서 다른 날짜를 인쇄합니다. 또한 new DateTime('@1740470400') 생성자에게 전달하는 모든 시간대를 무시합니다 @ 양식은 항상 UTC; 전화해야합니다 setTimezone() after. WordPress 는 자체 레이어를 추가합니다: current_time('timestamp') 가짜 "local"를 반환합니다. 실제 Unix 시간에서 타임 스탬프 오프셋이 울리는 것처럼 정확히 위험합니다.

파이썬:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

퀴크: fromtimestamp() 없이 tz= 순진한 데이터 시간을 현지 시간으로 반환합니다. 순진한 데이터 시간은 파이썬 시간 버그입니다: 둘 중 하나가 DST 경계를 넘을 때까지 서로 비교하고 행복하게 뺍니다. 항상 통과하십시오 tz=; 사용 zoneinfo (3.9부터 stdlib) 명명된 영역에 대해.

정신을 잃지 않고 시간대를 어떻게 처리해야 합니까?

네 가지 규칙, 모두 성가신 방법을 배웠습니다:

1. UTC를 저장하세요. 항상. 유닉스 타임스탬프 또는 timestamptz 데이터베이스에서.Timezone 은 디스플레이 관심사가 될 뿐이다.
2. 프레젠테이션 레이어에서 변환. 다카의 사용자가 봅니다 +06:00을, 베를린의 사용자가 본다 +02:00, 데이터베이스는 둘 다 보지 못합니다.
3. 약어가 아닌 IANA 이름을 사용하세요. Asia/Dhaka, America/New_York, Europe/Berlin. 약어가 모호하다 - CST 는 who's reading - 및 약어 don't 에 따라 미국 중부,중국 표준시 또는 쿠바 표준시를 의미하며 DST 규칙을 인코딩합니다. IANA 이름은.
4. 절대 핸드롤 DST 로직. DST 날짜는 국가별로 다르며 법률에 따라 변경되며 일부 장소 (애리조나,방글라데시, 일본) don't 는 DST 를 전혀 관찰하지 않습니다. IANA tz 데이터베이스는 이것이 진정으로 어렵 기 때문에 존재합니다; 그것을 감싸는 라이브러리를 사용하십시오.

규칙 1 의 결과: 두 시스템이 이벤트 시간에 대해 동의하지 않을 때 두 값을 모두 UTC Unix 타임스탬프로 변환하고 정수를 비교합니다. "에 대한 인수이지만 여기에 오후 3 시라고 나와 있습니다" 즉시 용해.

Y2038 문제는 무엇이며, 신경 써야합니까?

32비트 부호 있는 정수는 최대 1000m입니다 2,147,483,647. 유닉스 타임스탬프로서 that's 2038년 1월 19일 03:14:07 UTC. 1초 후 값은 1901년 12월 13일까지 음수로 감겨집니다.

멀리 소리; 그것은 isn't, 두 가지 이유. 첫째, it's 약 11.5 년 밖으로 내가이 글을 쓰는으로-잘 임베디드 시스템의 수명 내부, 산업 컨트롤러, 그리고 그 하나의 레거시 서비스 아무도 터치 하 고 싶어 둘째 미래 날짜가 일찍 벽에 부딪혔습니다: 15년 모기지 일정 또는 20년 인증서 만료를 계산하는 시스템은 2038년을 넘습니다 오늘. MySQL's TIMESTAMP 열 유형은 고전적인 함정입니다 - it's 32 비트-제한 및 can't 저장 날짜 지난 2038-01-19, 동안 DATETIME 같은 데이터베이스에서는 괜찮습니다.

You'64 비트에서 안전합니다 time_t (모든 최신 OS), JavaScript(float64ms), Python(임의 정밀도) 및 PostgreSQL. You'오래된 32비트 임베디드 시스템에서 위험에 처해 있습니다 TIMESTAMP 열 및 하드코딩된 C 코드입니다 int32_t 시간 동안. 시험은 간단합니다: 밀어 2147483648 (한계를 지나서) 파이프라인을 통해 무엇이 나오는지 확인하세요. The 타임스탬프 변환기 2038년 이후 테스트 값을 기꺼이 생성해 드립니다.

실제 디버깅에서 타임스탬프는 어디에 표시되나요?

JWT 만료. 토큰이 운반됩니다 iat 그리고 exp unix 초로 주장:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"이 사용자가 로그아웃한 이유는 무엇입니까?" 변환하여 답변합니다 exp. 에 있는 토큰을 해독하십시오 JWT 디코더 그리고 청구를 변환합니다. 둘 다 클라이언트 측을 실행합니다. 이는 붙여넣은 토큰이 실시간 자격 증명이기 때문에 중요합니다(the 데이터 개인정보 보호 가이드 내가 서버측 도구에 토큰을 넣는 것을 거부하는 이유를 다룹니다.).

로그 상관관계. 하나의 사건, 세 가지 서비스, 세 가지 형식: nginx 로그 [13/Jul/2026:09:30:45 +0000], 앱은 ISO 8601을 기록하고 대기열 작업자는 원시 epoch 초를 기록합니다. 모든 것을 하나의 형식으로 변환하는 것은 타임라인 구축의 0단계입니다.

API 통합. 스트라이프가 보냅니다 "created": 1740470400 (초). 자바스크립트로 빌드된 API가 전송합니다 1740470400000 (ms). Google APIs 는 RFC 3339 문자열을 보냅니다. 세 가지를 모두 소비하는 경우 변환 isn't 가끔 - it's 상수입니다. 에서 페이로드 포맷하기 JSON 포맷터 그리고 흥미로운 필드를 변환하세요.

날짜 범위 쿼리. WHERE created_at >= 1752364800 AND created_at < 1752451200- 그날이 맞는 날인가요? 경계와 체크를 모두 변환하고, UTC 에서는를,삭제를 실행하기 전에. Related: the 날짜 차이 계산기 for "이 둘 사이에 며칠?", the 시간대 변환기 회의 시간 수학을 위해 크론 파서 for "이 일정은 실제로 언제 실행됩니까?".

자주 묻는 질문

유닉스 타임스탬프란?

1970 년 1 월 1 일 00:00:00 UTC (유닉스 시대) 이후 경과된 초의 개수로,단일 정수로 저장된다. 정의상 It's timezone-independent - 같은 순간은 지구상의 모든 곳에서 같은 숫자이다 - 이것이 it's 운영체제,언어, 데이터베이스의 표준 교환 형식이다.

왜 일부 타임스탬프는 10 자리이고 다른 타임스탬프는 13 자리일까요?

10 자리는 초 (표준 유닉스 규약,PHP, 대부분의 API); 13 자리는 밀리초 (JavaScript's Date.now(), 자바). 1,000 로 나누어 ms 에서 초로 이동합니다. 두 교대 날짜를 혼란스럽게하는 것은 ~ 55,000 년 후 또는 1970 년 1 월로 돌아갑니다.

유닉스 타임스탬프는 1970 년 이전의 날짜를 나타낼 수 있는가?

예 - 음수 값은 시대부터 거꾸로 계산됩니다. -86400 는 1969 년 12 월 31 일입니다. 32 비트 부호 있는 타임스탬프는 1901 년 12 월 13 일로 되돌아갑니다. 하지만 일부 시스템과 API 는 네거티브 타임스탬프를 거부하므로 이에 의존하기 전에 테스트하십시오.

Y2038 문제는 무엇인가?

32 비트 부호 있는 타임스탬프는 2,147,483,647 에서 오버플로 - 2038 년 1 월 19 일, 03:14:07 UTC - 1901 년 12 월까지 래핑. 최신 64 비트 시스템은 영향을 받지 않지만 32 비트 임베디드 장치, 레거시 C 코드 및 MySQL TIMESTAMP 열이 노출됩니다. 먼 미래의 날짜 (모기지,인증서) 를 계산하는 시스템은 2038 이 도착하기 몇 년 전에 버그에 부딪혔습니다.

내 데이트 상대가 1970 년 1 월을 표시하는 이유는 무엇입니까?

0 또는 거의 0 에 가까운 타임스탬프가 포맷팅 코드에 도달했습니다 - 일반적으로 초기화되지 않은 값,0 을 반환하는 실패한 구문 분석 또는 밀리 초가 예상되는 초가 지났습니다. 화면의 1970 날짜는 거의 데이터 포인트가 아닙니다; it's 의상을 입은 널.

타임스탬프나 datetime 문자열을 데이터베이스에 저장해야 합니까?

UTC 를 어느 쪽이든 저장하십시오 - 유형은 timezone 분야 보다는 보다 적게 중요합니다. 유닉스 정수는 조밀하고,사소하게 분류하고,전적으로 구문 분석을 피합니다; timestamptz/DATETIME 열은 쿼리 결과에서 사람이 읽을 수 있으며 SQL 에서 날짜 산술을 지원합니다. 하지 말아야 할 것은 오프셋 없이 로컬 시간을 저장하는 것입니다 - that's 데이터 손실은 다음 DST 전환에서만 발견 할 수 있습니다.

에포크는 윤초의 영향을 받나요?

실질적으로는 아닙니다. 유닉스 시간은 윤초 don't 가 존재하는 척합니다 - 매일 정확히 86,400 초이며,시스템은 일반적으로 윤초가 발생할 때 시계를 번지거나 밟습니다. 애플리케이션 코드의 경우 이는 문제가 되지 않습니다; TAI 또는 GPS 시간이 대신 사용되는 과학적 타이밍 컨텍스트에서만 중요합니다.

온라인 변환기에 생산 로그 타임스탬프를 붙여넣는 것이 안전한가요?

원시 타임스탬프만으로는 거의 드러나지 않지만 타임스탬프는 일반적으로 사용자 ID, 토큰 주장, 로그 라인 등 컨텍스트를 사용하여 이동합니다. 그만큼 타임스탬프 변환기 에 Toolz.dev 변환 완전히 귀하의 브라우저에서 전송되는 데이터없이, 그래서 바로 생산 로그 또는 JWTs doesn't에서 값을 붙여 넣기 아무것도 노출.

Unix 타임스탬프를 읽을 수 있는 날짜로 변환하려면 어떻게 해야 하나요?

번호를 변환기에 붙여넣고 UTC 및 로컬 결과를 읽거나 코드로 수행하십시오: new Date(ts * 1000).toISOString() 자바스크립트에서는 datetime.fromtimestamp(ts, tz=timezone.utc) 파이썬에서는 date -u -d @ts 리눅스에서. 먼저 바로 잡는 한 가지는 당신의 값이 초 단위인지 밀리초 단위인지입니다. 다른 모든 것은 그로부터 따릅니다.

현재 Unix 타임스탬프를 어떻게 얻나요?

date +%s 껍질 속에서, Math.floor(Date.now() / 1000) 자바스크립트에서는 int(time.time()) 파이썬에서는 SELECT EXTRACT(EPOCH FROM NOW()) postgresql 에서. 자바 스크립트는 이상한 것을 밖으로 참고: Date.now() 밀리초를 반환하므로 분할은 선택 사항이 아닙니다.