Unix 타임스탬프 변환기

에포크 초 = 1970-01-01 이후 지난 날수 × 86400 + UTC 자정 이후 지난 초; 날짜와 시각 = 같은 계산을 거꾸로

mode

어느 방향으로 갈지 고릅니다. 타임스탬프를 넣고 날짜를 받거나, 날짜와 시각을 넣고 타임스탬프를 받습니다

timestamp

세어진 수 자체. 단위 항목에 따라 초이거나 밀리초입니다. 타임스탬프를 날짜로 바꾸는 방향에서만 씁니다

unit

넣은 수가 초를 세는지(이번 세기의 날짜라면 10자리), 밀리초를 세는지(13자리)를 정합니다. 타임스탬프를 날짜로 바꾸는 방향에서만 씁니다

date

UTC 기준의 달력 날짜. YYYY-MM-DD로 씁니다. 날짜를 타임스탬프로 바꾸는 방향에서만 씁니다

time

UTC 기준의 시계 시각. HH:MM 또는 HH:MM:SS로 씁니다. 날짜를 타임스탬프로 바꾸는 방향에서만 씁니다

utcDate

그 타임스탬프가 떨어지는 달력 날짜(UTC). 대표 결과입니다

utcTime

UTC 기준의 시계 시각. 항상 초까지 표시되며, 입력에 있던 초 미만의 값은 반올림하지 않고 버립니다

utcWeekday

그 날짜의 요일. 일요일을 0으로 하는 0–6의 숫자입니다

isoDateTime

2026-01-15T12:00:00Z 같은 ISO 8601 전체 형식. 코드나 로그에 그대로 붙여 넣을 수 있습니다

timestampSeconds

같은 순간을 1970-01-01T00:00:00Z 이후 정수 초로 나타낸 값. 반올림하지 않고 버리므로 위의 시각과 어긋나지 않습니다

timestampMilliseconds

같은 순간의 밀리초 값. 초 값에 1000을 곱한 것이며, 입력이 지니고 있던 초 미만의 부분도 그대로 남습니다

수와 날짜를 짝지어야 할 때 씁니다. 서버 로그나 API 응답, 데이터베이스 행에서 타임스탬프를 읽을 때, 받은 값이 초인지 밀리초인지 확인할 때, 저장할 타임스탬프를 만들 때 모두 이 페이지로 시작합니다. 이 페이지는 의도적으로 UTC에서 멈춥니다. 현지 시각으로 바꾸지 않고, 내가 어느 시간대에 있는지도 묻지 않습니다. Unix 타임스탬프에는 시간대가 없으므로 정직한 답은 UTC의 답이고, 그것을 현지 시계로 읽는 일은 시간대 계산기의 몫입니다. 타임스탬프끼리의 덧셈과 뺄셈도 하지 않습니다. 이 값에 30일을 더한 날짜가 필요하다면 먼저 변환하고 날짜 계산기를 쓰시기 바랍니다.

1. 1768478400, 기준이 되는 순간

   1. 단위가 초이므로 이 수는 이미 에포크 값입니다. 읽기 전에 환산할 것이 없습니다
   2. 86400으로 나누면 1970년 1월 1일 이후 지난 온전한 날수가 나오고, 나머지가 그날의 시각입니다. 결과는 2026년 1월 15일 12:00:00 UTC에 떨어집니다
   3. 2026년 1월 15일은 목요일이므로 요일 숫자는 4입니다
   4. 전체 형식으로 쓰면 2026-01-15T12:00:00Z이고, 이것이 로그나 API가 기대하는 모양입니다
   5. 밀리초 줄은 같은 순간에 1000을 곱한 값입니다. 어떤 시스템이 같은 순간을 밀리초로 보고할 때의 모습입니다

   이 페이지가 처음 열릴 때 보여 주는 값이고, 1768478400은 2026년 1월 15일 정오 UTC라는 기준점으로 외워 둘 만합니다. 한국 시간으로는 같은 날 21:00입니다. 기준점 하나가 익숙해지면 나머지 변환이 훨씬 쉬워집니다. 틀린 답은 보통 온전한 날짜만큼 어긋나거나 1000배만큼 어긋나고, 둘 다 아는 기준점과 견주면 바로 드러나기 때문입니다.

2. 2147483647, 32비트 시대의 마지막 1초

   1. 2147483647은 2의 31제곱에서 1을 뺀 수입니다. 부호 있는 32비트 정수가 담을 수 있는 가장 큰 값입니다
   2. 이것을 에포크 초로 읽으면 2038년 1월 19일 03:14:07 UTC이고, 이것이 2038년 문제의 내용입니다. 그 형식으로 타임스탬프를 저장하는 시스템은 1초 뒤에 자리가 없어 1901년의 날짜로 되돌아갑니다
   3. 2038년 1월 19일은 화요일이므로 요일 숫자는 2입니다
   4. 초 줄은 넣은 수를 그대로 돌려줍니다. 값이 같은 계산을 거쳐 들어가고 나왔는지 확인하는 자리입니다

   아래 참고표의 한 줄을 계산기에 그대로 넣어 본 것입니다. 2038년 문제는 그 날짜에 닿을 수 없다는 말이 아니라(이 페이지는 아무 불평 없이 계산합니다), 부호 있는 32비트 계수기를 쓰는 프로그램이 그다음 1초를 나타내지 못한다는 말입니다. 64비트 계수기에는 문제가 될 만한 지평선 안에서 그런 경계가 없고, 그래서 같은 값을 밀리초로 쓰면 2147483647000입니다.

3. 소수부가 있는 밀리초 값: 1768478400500

   1. 자릿수가 13이고 단위가 밀리초이므로, 첫 번째 예와 같은 순간에 0.5초를 더한 값입니다
   2. 시계 시각은 소수부를 반올림하지 않고 버리므로 12:00:01이 아니라 12:00:00으로 읽힙니다
   3. 초 줄도 같은 기준으로 잘라 1768478401이 아니라 1768478400입니다
   4. 밀리초 줄은 소수부를 그대로 지닙니다. 결과 안에서 그 부분이 존재하는 곳은 거기 하나뿐입니다

   반올림과 버리기가 갈라지는 유일한 경우이고, 초 줄이 왜 버리는지 보여 주는 자리입니다. 0.5초를 반올림하면 바로 위의 시계 시각보다 1 큰 초 값이 찍히고, 두 줄을 나란히 본 사람은 둘 중 하나가 고장 났다고 결론 내리게 됩니다. 보이는 시각과 모든 줄이 맞아떨어지는 쪽이 가장 가까운 정수를 지키는 것보다 중요합니다.

4. 반대 방향: 2026년 1월 15일 12:00:30 UTC

   1. 날짜를 1970년 1월 1일 이후의 날수로 바꾸고 86400을 곱해 자정까지의 초를 구합니다
   2. 자정에서 30초 지난 시각을 더합니다. 합계는 1768478430이고, 이것은 첫 번째 예의 값에 30을 더한 수입니다
   3. 시각 항목은 초를 받으므로 12:00:30이 분 단위로 잘리지 않고 그대로 읽힙니다
   4. 날짜와 요일 줄은 그대로 돌아옵니다. 밖으로 나갔다가 다시 들어오는 것이 항등 연산이기 때문입니다

   이미 변환한 값에 반대 방향을 걸어 보는 것이 타임스탬프를 확인하는 가장 싼 방법입니다. 왕복이 처음 수로 돌아오지 않으면 단위가 틀렸을 가능성이 큽니다. 단위가 밀리초인 상태에서 10자리 수를 넣으면 1000배만큼 어긋나는데, 이것은 오류로 나타나지 않고 1970년 1월의 날짜로 나타납니다.

이 페이지가 알려 주는 모든 값은 UTC이고, 현지 시간대로 변환하지 않습니다. Unix 타임스탬프는 시간대 없이 정의되므로, 그것을 현지 시계로 읽는 일은 시간대 계산기의 몫입니다. 다루는 구간은 1970-01-01T00:00:00Z부터 2100-12-31T23:59:59Z까지이고, 이 밖의 값은 조용히 계산되지 않고 거부됩니다. 음수 타임스탬프는 에포크 이전 날짜에 대해 합법적인 Unix 타임스탬프이지만, 이 페이지는 그렇게 밝히고 멈춥니다. 스스로 선언한 구간과 어긋나는 1969년의 답을 돌려주는 것보다 낫기 때문입니다. 초 미만의 값은 반올림하지 않고 버리므로, 밀리초 값이 정밀도를 잃지는 않지만 표시되는 초에 영향을 주지도 않습니다. 이 페이지는 다른 형식의 날짜 문자열을 읽지 않고, 지금 이 기기의 시각도 읽지 않으며, 타임스탬프끼리의 덧셈과 뺄셈도 하지 않습니다. 변환한 값에서 30일 뒤의 날짜가 필요하다면 날짜 계산기를 쓰시기 바랍니다.

에포크 시간이란 무엇인가요?

에포크 시간은 1970-01-01T00:00:00 UTC 이후 지나간 초의 수입니다. Unix 시스템이 세는 영점입니다. Unix 시간이나 POSIX 시간이라고도 부릅니다. 어디에 있는지와는 무관합니다. 에포크 시간은 UTC로 정의되므로 같은 순간은 세계 어디서나 같은 값이고, 현지 시계에 대해 서로 다른 의견을 가진 두 기기도 타임스탬프에 대해서는 의견이 같습니다. 이 페이지가 보여 주는 1768478400은 한국 시간으로 2026년 1월 15일 21:00이지만, 값 자체는 그 표기를 담고 있지 않습니다.

타임스탬프를 날짜로 바꾸려면 어떻게 하나요?

값을 넣고 그것이 초를 세는지 밀리초를 세는지 고른 다음, 돌아오는 날짜와 시각을 읽습니다. 먼저 확인할 것은 자릿수입니다. 이번 세기의 날짜에 대한 초는 10자리이고 밀리초는 13자리입니다. 13자리 값을 초로 읽으면 몇만 년 뒤로 가서 거부되고, 10자리 값을 밀리초로 읽으면 1970년 1월에 떨어집니다. 뒤쪽이 스스로 알려 주지 않는 실수입니다. 반대 방향으로 되돌려 보는 것이 가장 빠른 확인입니다.

2038년 문제는 무엇인가요?

2038년 문제는 시스템이 타임스탬프를 부호 있는 32비트 정수에 저장할 때 생기는 일입니다. 그 형식이 담을 수 있는 가장 큰 값은 2147483647이고 이것이 2038-01-19T03:14:07 UTC이며, 1초 뒤에 계수기가 넘쳐 1901년의 날짜로 되돌아갑니다. 타임스탬프 자체의 한계가 아니라 저장 형식의 한계이고, 64비트 계수기에는 이 문제가 없습니다. 이 페이지는 그 값과 그 뒤의 값도 문제없이 변환합니다. 32비트 정수가 아니라 배정밀도로 계산하기 때문입니다.

초와 밀리초 가운데 무엇을 저장해야 하나요?

둘 다 널리 쓰이고 어느 쪽도 틀리지 않았습니다. 다만 값 하나만으로는 어느 쪽인지 알 수 없으므로, 단위가 수와 함께 다니거나 미리 합의되어 있어야 합니다. 밀리초는 초 미만을 보존하며 자바스크립트의 Date 객체와 여러 로깅 시스템이 쓰는 단위입니다. 초는 POSIX가 정의한 단위이고 대부분의 API와 데이터베이스가 돌려주는 값입니다. 둘 사이의 변환은 1000을 곱하거나 나누는 일이고, 이 페이지는 두 줄을 함께 보여 주므로 짝이 한눈에 보입니다.

ISO 8601 형식은 타임스탬프와 같은 것인가요?

아닙니다. 둘 다 같은 순간을 설명하기 때문에 헷갈리기 쉽습니다. ISO 8601은 2026-01-15T12:00:00Z처럼 적어 놓은 형식이고, 사람이 읽을 수 있으며 정렬이 되고 끝의 Z로 UTC 오프셋을 분명히 밝힙니다. Unix 타임스탬프는 서식이 전혀 없는 수 하나입니다. 문서나 URL에 붙여 넣는 것은 ISO 8601 문자열이고, 저장하거나 비교하는 것은 수입니다. 이 페이지는 같은 변환에서 둘을 함께 출력하므로 서로 맞는지 확인할 수 있습니다.

• The Open Group Base Specifications, Seconds Since the Epoch — 에포크와 윤초 처리의 규범적 정의 — The Open Group
• RFC 3339, Date and Time on the Internet: Timestamps — 이 페이지가 출력하는 Z 표기 문자열의 형식 — IETF
• MDN, Date — 자바스크립트의 밀리초 계수와 그 범위 — MDN Web Docs