Unix 타임스탬프란: 초와 밀리초 구분, 2038년 문제, 언어별 변환 코드

Unix 타임스탬프란 무엇인가

Unix 타임스탬프, 다른 말로 Unix 시간 또는 epoch 시간은 1970년 1월 1일 00:00:00 UTC, 이른바 "Unix epoch"부터 지금까지 흐른 초의 개수입니다. 그냥 정수이기 때문에 데이터베이스, API, 로그 파일이 좋아합니다. 정렬이 올바르게 되고, 뺄셈이 깔끔하고, 많아야 8바이트입니다. 예를 들어 1790726400은 2026년 9월 30일 00:00:00 UTC입니다. 한국 시간으로는 같은 날 오전 9시, 밴쿠버로는 9월 29일 오후 5시이지만 숫자는 어디서나 같습니다.

정의에서 따라 나오는 사실이 둘 있습니다. 1970년 이전 날짜는 음수입니다. 하루가 86,400초이므로 -86400은 1969년 12월 31일입니다. 그리고 윤초는 세지 않습니다. Unix 시간은 모든 날이 정확히 86,400초라고 가정하므로, 타임스탬프를 변환해서 23:59:60이 나오는 일은 없습니다.

초인가 밀리초인가, 자릿수를 세세요

타임스탬프에서 가장 흔한 실수는 단위를 섞는 것입니다. 전통적인 Unix 시간은 초 단위이고 2001년부터 2286년 사이의 날짜라면 10자리입니다. JavaScript의 Date.now(), Java의 System.currentTimeMillis(), 많은 JSON API는 밀리초를 쓰고 그러면 13자리가 됩니다. 1790726400000은 위와 같은 자정입니다. 더 나아가 마이크로초는 16자리, 나노초는 19자리를 쓰는 시스템도 있습니다.

13자리 값을 초로 설정된 변환기에 넣으면 서기 5만 8천 년쯤의 날짜가 나오고, 10자리 값을 밀리초로 넣으면 1970년 초로 떨어집니다. 무엇을 하기 전에 자릿수부터 세세요. Unix 타임스탬프 변환기는 추측하지 않습니다. '초'와 '밀리초' 버튼이 숫자를 읽는 방식을 결정하고, ISO 8601 줄을 보면 잘못 고른 것이 바로 드러납니다.

시간대가 적용되지 않는 이유

타임스탬프는 시계의 눈금이 아니라 하나의 순간입니다. 서울과 밴쿠버에서 1790726400을 보는 두 사람은 같은 순간을 보고 있고, 다른 것은 그 순간을 적을 때의 현지 시각뿐입니다. 그러므로 "한국 시간 타임스탬프"나 "현지 타임스탬프"에 대비되는 "UTC 타임스탬프" 같은 것은 없습니다. 시간대는 사람이 읽는 날짜를 만들 때, 또는 그런 날짜를 파싱할 때만 등장합니다.

버그가 숨는 곳이 바로 두 번째 경우입니다. 2026-09-30이나 2026-09-30 09:00처럼 시간대가 없는 날짜는 모호합니다. 한국 시간으로 파싱하면 어떤 타임스탬프가 되고, 밴쿠버 시간으로 파싱하면 16시간 떨어진 다른 타임스탬프가 됩니다. 해결책은 ISO 8601처럼 문자열에 시간대를 함께 싣는 것(2026-09-30T00:00:00Z 또는 2026-09-30T09:00:00+09:00)과, 현지 시각 문자열 대신 타임스탬프를 저장하는 것입니다.

코드로 변환하기

JavaScript는 밀리초로 일하므로 1,000으로 나누거나 곱합니다.

• 현재 타임스탬프(초): Math.floor(Date.now() / 1000)
• 타임스탬프 → 날짜: new Date(1790726400 * 1000).toISOString()은 "2026-09-30T00:00:00.000Z"
• 날짜 → 타임스탬프: Math.floor(Date.parse("2026-09-30T00:00:00Z") / 1000)은 1790726400

Python은 초 단위 실수로 일합니다. 시간대 정보가 없는 datetime은 컴퓨터의 현지 시간대로 해석되므로 항상 시간대를 넘기세요(아래 예시는 from datetime import datetime, timezone을 전제합니다).

• 현재 타임스탬프: import time; int(time.time())
• 타임스탬프 → 날짜: datetime.fromtimestamp(1790726400, tz=timezone.utc)는 2026-09-30 00:00:00+00:00
• 날짜 → 타임스탬프: int(datetime(2026, 9, 30, tzinfo=timezone.utc).timestamp())는 1790726400

SQL은 데이터베이스마다 다르고, 표시 함수는 세션의 시간대를 쓰므로 결과가 한 시간 이상 어긋나 보이면 세션 시간대부터 확인하세요.

• MySQL: SELECT UNIX_TIMESTAMP();와 SELECT FROM_UNIXTIME(1790726400);
• PostgreSQL: SELECT EXTRACT(EPOCH FROM now())::bigint;와 SELECT to_timestamp(1790726400);
• SQLite: SELECT strftime('%s', 'now');와 SELECT datetime(1790726400, 'unixepoch');는 2026-09-30 00:00:00

엑셀과 구글 스프레드시트는 날짜를 일수로 저장하므로, A1 셀의 타임스탬프는 =A1/86400 + DATE(1970,1,1)에 날짜·시간 서식을 입히면 날짜가 됩니다. 결과는 UTC이니 한국 시간은 9시간, 즉 +9/24를 더하세요. 반대 방향은 =(A1 - DATE(1970,1,1)) * 86400입니다. 밀리초라면 86,400,000으로 나눕니다.

2038년 문제

오래된 시스템 중에는 Unix 시간을 부호 있는 32비트 정수로 저장하는 것이 많은데, 그 최댓값이 2,147,483,647입니다. 이 값은 2038년 1월 19일 03:14:07 UTC, 한국 시간으로 같은 날 낮 12시 14분 7초입니다. 1초 뒤 값은 −2,147,483,648로 넘어가 1901년 12월 13일로 읽히고, 그 위에서 날짜 계산을 하는 것은 전부 깨집니다. 최신 64비트 운영체제와 언어, JavaScript 포함, 는 영향이 없지만 임베디드 기기, 오래된 파일 형식, 구버전 MySQL의 TIMESTAMP 컬럼 타입에는 아직 이 한계가 남아 있습니다. 타임스탬프를 저장한다면 64비트 정수를 쓰고, 2010년 전후 이전에 만들어진 것을 관리하고 있다면 한 번 확인해 볼 만합니다.

변환기 사용법

Unix 타임스탬프 변환기는 현재 타임스탬프를 1초마다 갱신하며 실시간으로 보여 줍니다. 아무 값이나 붙여 넣고 '초' 또는 '밀리초'를 고르면 ISO 8601, UTC 문자열, 브라우저 시간대의 로컬 문자열, 두 단위의 타임스탬프, 그리고 "3일 전" 같은 상대 시간으로 읽어 줍니다. '날짜 → 타임스탬프' 패널은 반대 방향입니다. 입력한 날짜와 시간은 브라우저 시간대로 읽히므로, 한국 시간으로 맞춰진 노트북에서 09:00을 넣으면 UTC 00:00이 됩니다. 어느 패널이든 입력을 시작하면 실시간 시계가 멈춰서 결과를 복사하기 편하고, 줄마다 복사 버튼이 있습니다.

상대 시간은 가장 큰 단위로 내림하고 한 달을 30일로 치는 대략적인 확인용입니다. 두 날짜 사이의 정확한 일수는 날짜 계산기를 쓰세요. 타임스탬프의 UTC 값을 다른 도시의 시각으로 바꾸려면 시간대 변환기가 해당 날짜의 서머타임까지 처리합니다. 타임스탬프는 대개 API 응답 안에 실려 오는데, 숫자로 보낼지 문자열로 보낼지라는 관련 질문은 JSON 포맷팅 가이드에서 다룹니다.

무료 Unix 타임스탬프 변환기 열기 — 현재 epoch 시간을 실시간으로, 양방향 변환과 함께.