유닉스 타임스탬프 변환기

1704067200은 2024년 1월 1일 0시(UTC), 한국 시각으로 오전 9시입니다

유닉스 타임스탬프(유닉스 시간)는 1970년 1월 1일 00:00:00 UTC를 0으로 두고 그 뒤로 지난 초를 센 숫자입니다. 1704067200은 2024년 1월 1일 00:00:00 UTC이고, UTC보다 9시간 빠른 한국에서는 같은 날 오전 9시입니다. 13자리 1704067200000은 같은 순간을 밀리초로 센 값입니다.

위 변환기의 숫자 칸에 값을 붙여 넣으면 자릿수로 초·밀리초·마이크로초·나노초를 가려 날짜로 바꾸고, 날짜 칸에 날짜와 시각을 넣으면 거꾸로 숫자를 만듭니다. 시간대를 고르면 그 지역의 서머타임과 옛 표준시까지 반영하며, 맨 위 띠에서는 지금 이 순간의 유닉스 시간이 1초마다 바뀝니다. 아래 숫자선은 넣은 값이 32비트 정수에 담기는지를 보여 줍니다.

시간을 숫자 하나로 적는 까닭과 이 변환이 필요한 순간

'2024년 1월 1일 오전 9시'처럼 적은 날짜는 어느 나라 시각인지, 그때 서머타임이었는지를 함께 알아야 같은 순간을 가리킵니다. 유닉스 시간은 지구 어디에서나 같은 순간에 같은 숫자라서 서버 로그·데이터베이스·API가 시각을 주고받을 때 널리 씁니다. 두 값을 빼면 그 사이에 흐른 초가 바로 나오고, 크기를 비교하면 먼저 일어난 일을 알 수 있습니다.

대신 사람이 숫자만 보고는 날짜를 알 수 없습니다. 다음과 같은 순간에 변환이 필요합니다.

로그를 읽을 때: 오류가 난 시각이 1760000000처럼 숫자로만 찍혀 있으면 한국 시각으로 몇 시였는지 바꿔 봐야 다른 기록과 맞출 수 있습니다.
API 응답·토큰을 확인할 때: 로그인 토큰(JWT)의 exp·iat·nbf 값은 RFC 7519가 정한 NumericDate, 곧 1970-01-01T00:00:00Z부터 센 초입니다. 만료 시각이 이미 지났는지 날짜로 확인합니다.
데이터베이스에서 구간을 조회할 때: '2024년 1월 하루치'를 숫자 열로 찾으려면 그날 0시와 다음 날 0시의 타임스탬프가 필요합니다. 위 '그날·그달·그해의 시작과 끝'이 그 값을 줍니다.
엑셀로 받은 숫자 열을 날짜로 바꿀 때: 내려받은 자료의 날짜 열이 10자리·13자리 숫자라면 단위와 시간대를 정해 식으로 바꿔야 합니다(엑셀 절).
날짜를 숫자로 넣어야 할 때: 예약 발송 시각·만료 시각처럼 설정값을 타임스탬프로 받는 프로그램에 특정 한국 시각을 넣을 때입니다.

계산 방법: 하루를 늘 86,400초로 셉니다

POSIX 표준은 1970년 1월 1일 00:00:00 UTC를 기준점(Epoch)으로 두고, 기준점부터 지난 시간을 셀 때 하루를 정확히 86,400초로 칩니다. 그래서 날짜를 숫자로 바꾸는 계산은 '기준점부터 그날 전까지의 날수 × 86,400 + 그날 0시부터 지난 초'입니다.

날짜·시각을 UTC로 바꿉니다: 한국 시각이면 9시간을 뺍니다. 2024년 1월 1일 09:00(한국)은 2024년 1월 1일 00:00 UTC입니다.
1970년 1월 1일부터 그날 전까지의 날수를 셉니다: 1970~2023년은 54년 × 365일 = 19,710일에 윤년 13번(1972·1976·…·2020)의 하루씩을 더해 19,723일입니다.
날수 × 86,400에 그날의 시 × 3,600 + 분 × 60 + 초를 더합니다: 19,723 × 86,400 + 0 = 1,704,067,200초입니다.
단위를 맞춥니다: 밀리초는 1,000을, 마이크로초는 1,000,000을, 나노초는 1,000,000,000을 곱합니다.

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400POSIX.1-2024 4.19 Seconds Since the Epoch(1970년 이후 날짜에 쓰는 식, 나눗셈은 정수 나눗셈). 같은 절은 "each and every day shall be accounted for by exactly 86400 seconds"라고 적습니다.

숫자를 날짜로 바꿀 때는 거꾸로 86,400으로 나눕니다. 1,704,067,200 ÷ 86,400 = 19,723, 나머지 0이므로 1970년 1월 1일에서 19,723일 뒤인 2024년 1월 1일 0시 0분 0초 UTC입니다. 이 변환기는 이 계산을 나노초 단위의 큰 정수로 하고, 고른 시간대의 시각은 브라우저의 IANA 시간대 자료로 그 순간의 실제 차이를 더해 보여 줍니다.

자릿수로 단위 알아보기: 10·13·16·19자리

타임스탬프에는 단위가 적혀 있지 않습니다. 같은 순간이라도 초로 세면 10자리, 밀리초로 세면 13자리가 됩니다. 요즘 날짜의 자릿수와 이 변환기의 자동 판별 기준은 다음과 같습니다.

같은 순간(2024-01-01 00:00:00 UTC)을 단위별로 적은 값
단위	값	자릿수	자동 판별(정수 부분)	주로 쓰는 곳
초 (s)	1704067200	10	1천억(10¹¹) 미만	PHP time(), MySQL UNIX_TIMESTAMP(), JWT, date +%s
밀리초 (ms)	1704067200000	13	10¹¹ 이상 10¹⁴ 미만	JavaScript Date.now(), Java System.currentTimeMillis()
마이크로초 (µs)	1704067200000000	16	10¹⁴ 이상 10¹⁷ 미만	Go UnixMicro()
나노초 (ns)	1704067200000000000	19	10¹⁷ 이상	Python time.time_ns(), Go UnixNano()

이 경계에서는 1973년 3월 3일 09:46:40 UTC부터 5138년 11월 16일 09:46:40 UTC까지의 순간이 어느 단위로 적혀 있어도 맞게 가려집니다. 1970년부터 1973년 3월 초까지의 밀리초 값처럼 경계보다 작은 숫자는 한 단계 작은 단위로 읽히니, 원본 단위를 알면 '단위'에서 직접 고르세요. 11·14·17자리처럼 흔하지 않은 자릿수에는 화면에 확인 안내가 붙습니다.

단위를 잘못 읽으면 날짜가 크게 틀어집니다. 10자리 1704067200을 밀리초로 읽으면 1970년 1월 20일 17:21:07.200 UTC가 되고, 13자리 1704067200000을 초로 읽으면 약 5만 4천 년 뒤인 5만 5,970년 무렵이라 이 변환기의 범위(9999년)를 벗어납니다. 날짜가 1970년 1월에 몰려 있거나 0001~9999년 범위를 벗어났다는 안내가 나오면 단위부터 확인하세요.

예시로 보는 변환

입력값 → UTC와 서울 시각(괄호는 요일)
입력	단위	UTC	서울
0	초	1970-01-01 00:00:00 (목)	1970-01-01 09:00:00 (목)
-1	초	1969-12-31 23:59:59 (수)	1970-01-01 08:59:59 (목)
1704034800	초	2023-12-31 15:00:00 (일)	2024-01-01 00:00:00 (월)
1704067200	초	2024-01-01 00:00:00 (월)	2024-01-01 09:00:00 (월)
1704067200.5	초	2024-01-01 00:00:00.500 (월)	2024-01-01 09:00:00.500 (월)
1704067200123	밀리초	2024-01-01 00:00:00.123 (월)	2024-01-01 09:00:00.123 (월)
1704067200123456	마이크로초	2024-01-01 00:00:00.123456 (월)	2024-01-01 09:00:00.123456 (월)
1704067200123456789	나노초	2024-01-01 00:00:00.123456789 (월)	2024-01-01 09:00:00.123456789 (월)
581133600	초	1988-06-01 02:00:00 (수)	1988-06-01 12:00:00 (수, 서머타임 UTC+10)

1704034800은 한국의 2024년 새해 0시입니다. 한국 날짜를 넣었는데 UTC 날짜는 하루 전으로 나오는 이유는 한국이 UTC보다 9시간 앞서 있기 때문이며, 두 표기가 가리키는 순간은 같습니다.

기억해 둘 만한 숫자

타임스탬프 → UTC와 서울 시각
값(초)	UTC	서울	뜻
0	1970-01-01 00:00:00	1970-01-01 09:00:00	기준점(Epoch)
1,000,000,000	2001-09-09 01:46:40	2001-09-09 10:46:40	처음 10자리가 된 순간(10억 초)
1,234,567,890	2009-02-13 23:31:30	2009-02-14 08:31:30	숫자가 1부터 0까지 차례로 놓인 순간
1,800,000,000	2027-01-15 08:00:00	2027-01-15 17:00:00	18억 초(1억 단위로 딱 떨어지는 값)
2,000,000,000	2033-05-18 03:33:20	2033-05-18 12:33:20	20억 초
2,147,483,647	2038-01-19 03:14:07	2038-01-19 12:14:07	부호 있는 32비트 최댓값(2³¹−1)
−2,147,483,648	1901-12-13 20:45:52	1901-12-14 05:13:44	부호 있는 32비트 최솟값(서울은 지방 평균시 +8:27:52)
4,294,967,295	2106-02-07 06:28:15	2106-02-07 15:28:15	부호 없는 32비트 최댓값(2³²−1)

나노초를 부호 있는 64비트 정수에 담으면 가장 큰 값 9,223,372,036,854,775,807은 2262년 4월 11일 23:47:16.854775807 UTC입니다. Go 문서도 UnixNano()가 1678년 전이나 2262년 뒤의 날짜에서는 결과가 정의되지 않는다고 적습니다.

2038년 문제: 32비트 정수에 담긴 시각

초를 부호 있는 32비트 정수에 저장하면 담을 수 있는 가장 큰 값은 2,147,483,647, 곧 2038년 1월 19일 03:14:07 UTC(한국 낮 12시 14분 7초)입니다. 그다음 1초는 이 칸에 들어가지 않습니다. 넘친 값이 가장 작은 음수 −2,147,483,648로 바뀌면 시각이 1901년 12월 13일 20:45:52 UTC로 읽힙니다.

부호 없는 32비트 정수는 음수를 담지 못하는 대신 2106년 2월 7일 06:28:15 UTC까지 갑니다. 부호 있는 64비트 정수로 초를 세면 약 2,920억 년까지 담을 수 있어 사실상 끝이 없습니다. 위 숫자선의 두 띠가 이 두 범위이고, 표식이 띠 밖에 있으면 그 값은 해당 형식에 저장할 수 없습니다.

데이터베이스 열, 파일 형식, 오래된 장비처럼 32비트로 저장하는 곳에 2040년 만기일 같은 미래 날짜를 넣기 전에 확인하세요. MySQL 8.4 문서는 64비트 플랫폼에서 UNIX_TIMESTAMP()가 받는 값을 3001년(32536771199.999999초)까지로, 32비트 플랫폼은 2147483647.999999초까지로 적습니다.

언어·도구별 지금 값과 단위

타임스탬프를 만든 프로그램을 알면 단위도 알 수 있습니다. 각 공식 문서에 적힌 반환 단위는 다음과 같습니다.

지금 시각을 타임스탬프로 얻는 코드
환경	코드	단위	메모
JavaScript	`Date.now()`	밀리초	정수 13자리
Python	`time.time()` · `time.time_ns()`	초 · 나노초	time()은 소수가 붙은 실수
Java	`System.currentTimeMillis()`	밀리초	값의 정밀도는 운영체제에 따라 다름
PHP	`time()`	초	시간대 정보는 담지 않음
Go	`time.Now().Unix()` · `UnixMilli()` · `UnixNano()`	초 · 밀리초 · 나노초	UnixNano()는 1678~2262년만
MySQL	`UNIX_TIMESTAMP()`	초	날짜를 넣으면 세션 시간대로 읽음, 반대 방향은 `FROM_UNIXTIME()`
PostgreSQL	`EXTRACT(EPOCH FROM now())`	초	소수 초 포함, 반대 방향은 `to_timestamp()`
셸(GNU date)	`date +%s`	초	반대 방향은 `date -u -d @1704067200`
JWT	exp · iat · nbf	초	RFC 7519 NumericDate, 소수 허용

MySQL의 UNIX_TIMESTAMP('2024-01-01 00:00:00')처럼 날짜 글자를 넣는 함수는 연결(세션)의 시간대로 그 날짜를 읽습니다. 같은 식이라도 서버 시간대 설정에 따라 9시간 차이 나는 값이 나올 수 있으니, 결과를 이 변환기에 넣어 어느 시각으로 읽혔는지 확인하세요.

시간대와 한국 표준시의 변화

타임스탬프 숫자에는 시간대가 들어 있지 않습니다. 같은 1704067200이 서울에서는 2024년 1월 1일 오전 9시, 런던에서는 0시, 뉴욕에서는 전날 오후 7시로 보일 뿐 가리키는 순간은 하나입니다. 시간대는 숫자를 사람이 읽는 시각으로 보여 줄 때만 필요합니다.

한국 시각도 늘 UTC+9였던 것은 아닙니다. IANA 시간대 자료의 서울(Asia/Seoul) 기록은 다음과 같고, 이 변환기는 그 날짜에 실제로 쓰던 차이를 씁니다.

서울의 UTC와의 차이(IANA tzdb asia)
기간	UTC와 차이	여름 서머타임
1908년 4월 1일 전	+8:27:52	없음(서울 지방 평균시)
1908년 4월 1일 ~ 1911년 12월 31일	+8:30	없음
1912년 1월 1일 ~ 1954년 3월 20일	+9:00	1948~1951년 +10:00
1954년 3월 21일 ~ 1961년 8월 9일	+8:30	1955~1960년 +9:30
1961년 8월 10일부터	+9:00	1987·1988년 +10:00

그래서 1988년 6월 1일 정오(서울)는 581,133,600초입니다. 모든 날짜를 +9로 계산하면 581,137,200초가 되어 1시간 어긋납니다. 1988년 5월 8일 02:00~02:59는 시계를 한 시간 앞당기며 건너뛴 시각이고, 10월 9일 02:00~02:59는 시계를 되돌려 두 번 있었습니다. 날짜 칸에 없는 시각을 넣으면 건너뛴 만큼 뒤 시각으로, 두 번 있는 시각은 앞의 것(서머타임 쪽)으로 계산하고 그 사실을 칸 아래에 알립니다.

윤초는 세지 않습니다

원자시계로 잰 시간과 지구 자전의 차이를 맞추려고 1972년부터 2016년까지 UTC에 윤초가 27번 들어갔습니다. 유닉스 시간은 하루를 늘 86,400초로 세므로 2016년 12월 31일 23:59:60 UTC 같은 윤초 순간을 나타내는 숫자가 없습니다. 23:59:59(1483228799) 다음 값 1483228800이 바로 2017년 1월 1일 00:00:00 UTC입니다.

그래서 윤초를 사이에 둔 두 타임스탬프를 빼면 실제로 흐른 시간보다 1초 적게 나옵니다. 국제지구자전좌표국(IERS)은 2026년 7월 공보 C 72에서 2026년 12월 말에도 윤초를 넣지 않는다고 밝혔고, 2017년 1월 1일부터 UTC−TAI는 −37초입니다. 날짜 칸에 23:59:60을 넣으면 윤초가 없다는 안내가 나옵니다.

엑셀에서 유닉스 시간 바꾸기

엑셀의 1900 날짜 체계는 1900년 1월 1일부터 지난 날수를 일련번호로 씁니다. 그래서 초를 날짜로 바꾸려면 하루 86,400초로 나눈 뒤 1970년 1월 1일의 일련번호(25569)를 더합니다. A1에 값이 있을 때의 식은 다음과 같습니다.

엑셀 식(A1 = 타임스탬프 또는 날짜)
하려는 일	식	A1 = 1704067200일 때
초 → UTC 날짜	`=A1/86400+DATE(1970,1,1)`	45292 → 2024-01-01 00:00:00
초 → 한국 시각	`=A1/86400+DATE(1970,1,1)+9/24`	45292.375 → 2024-01-01 09:00:00
밀리초 → UTC 날짜	`=A1/86400000+DATE(1970,1,1)`	A1 = 1704067200000이면 45292
UTC 날짜 → 초	`=(A1-DATE(1970,1,1))*86400`	2024-01-01 00:00 → 1704067200
한국 시각 → 초	`=(A1-DATE(1970,1,1)-9/24)*86400`	2024-01-01 09:00 → 1704067200

식 결과는 숫자로 보이므로 칸 서식을 'yyyy-mm-dd hh:mm:ss' 같은 날짜·시간으로 바꿔야 합니다. +9/24는 1988년 서머타임 같은 옛 차이를 반영하지 못하니 오래된 날짜는 이 변환기로 확인하세요. Microsoft는 엑셀이 1900년을 윤년으로 잘못 가정한다고 밝히고 있어, 1900년 3월 1일 전 날짜는 일련번호가 실제와 하루 어긋납니다. 위 '엑셀·시트 날짜 값' 칸은 그 기간에는 값을 보여 주지 않습니다.

자주 틀리는 경우

밀리초를 초로 넣는 경우: 13자리를 초 칸에 넣으면 수만 년 뒤가 됩니다. 반대로 10자리를 밀리초로 읽으면 1970년 1월이 나옵니다.
한국 시각을 두 번 더하는 경우: 숫자에는 시간대가 없으므로 9시간을 더할 일은 숫자를 사람이 읽는 시각으로 바꿀 때 한 번뿐입니다. 로그에 이미 한국 시각 글자로 적힌 날짜에 또 9시간을 더하면 하루가 밀릴 수 있습니다.
엑셀 식에서 시간대를 빼먹는 경우: =A1/86400+DATE(1970,1,1)은 UTC입니다. 한국 시각이 필요하면 +9/24를 더해야 오전 9시 이전 기록의 날짜가 맞습니다.
32비트 칸에 2038년 이후 날짜를 넣는 경우: 저장 형식이 부호 있는 32비트면 2038년 1월 19일 03:14:07 UTC 뒤 값은 넘칩니다.
나노초를 자바스크립트 숫자로 다루는 경우: Number는 2⁵³(9,007,199,254,740,992)보다 큰 정수를 정확히 담지 못해 1704067200123456789가 1704067200123456800으로 바뀝니다. 나노초 값은 글자나 BigInt로 다루세요.

한계

UTC와 고른 시간대의 날짜가 모두 0001년 1월 1일 ~ 9999년 12월 31일 안인 값만 바꾸며, 나노초보다 작은 자리는 받지 않습니다. 1582년 이전 날짜도 지금의 그레고리력을 거꾸로 늘려 계산합니다.
윤초 순간(23:59:60)은 나타내지 않습니다. 유닉스 시간 자체에 그 순간의 숫자가 없기 때문입니다.
시간대별 시각은 이 브라우저에 들어 있는 IANA 시간대 자료를 씁니다. 자료가 오래된 브라우저에서는 최근에 바뀐 나라의 규칙이 늦게 반영될 수 있습니다.
'지금' 값과 '지금과의 차이'는 이 기기 시계 기준이라 기기 시계가 틀리면 함께 틀립니다. 지금과의 차이는 1년을 365.2425일로 보는 어림입니다.
'그날·그달·그해의 시작과 끝'은 고른 시간대의 0시 기준입니다. 0시가 서머타임으로 건너뛰는 지역에서는 그날 처음 있는 시각을 시작으로 씁니다.

출처

01The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch기준점부터 센 초의 식, "each and every day shall be accounted for by exactly 86400 seconds". Epoch 정의는 3.125(1970년 1월 1일 0시 UTC)
02IETF RFC 7519: JSON Web Token (JWT)2절 NumericDate: 1970-01-01T00:00:00Z부터 센 초, 윤초 무시, 소수 허용. 4.1.4~4.1.6 exp·nbf·iat
03IETF RFC 3339: Date and Time on the Internet: Timestamps5.6 date-time 형식, 시차는 ±hh:mm까지(초 단위 시차는 적을 수 없음)
04IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsHTTP 날짜의 기본 형식 IMF-fixdate, 예 "Sun, 06 Nov 1994 08:49:37 GMT"
05ECMAScript: Time Values and Time Range하루 86,400,000밀리초, 표현 범위 ±8,640,000,000,000,000밀리초(±1억 일)
06MDN: Date.now()"returns the number of milliseconds elapsed since the epoch"
07Python 문서: time.time()·time.time_ns()time()은 기준점부터 센 초(실수), time_ns()는 정수 나노초. 대부분의 유닉스 시스템은 윤초를 세지 않음
08Go time 패키지: Time.Unix·UnixMilli·UnixMicro·UnixNanoUnixNano()는 1678년 전이나 2262년 뒤면 결과가 정의되지 않음
09MySQL 8.4: UNIX_TIMESTAMP()·FROM_UNIXTIME()반환값은 초, 날짜 인수는 세션 시간대로 읽음, 64비트 플랫폼 상한 32536771199.999999초
10PostgreSQL: Date/Time Functions, EXTRACT(EPOCH)·to_timestamptimestamp with time zone의 epoch는 1970-01-01 00:00:00 UTC부터 센 초(이전은 음수)
11GNU coreutils: Seconds since the Epoch'@' 뒤의 숫자는 기준점부터 센 초, date +%s는 윤초를 세지 않음
12Microsoft: Excel incorrectly assumes that the year 1900 is a leap year1900 날짜 체계의 윤년 오류, 1900년 3월 1일 전 날짜의 요일 차이. 날짜 체계 설명은 Microsoft 지원 'Date systems in Excel'
13IERS Bulletin C 72 (2026년 7월 6일)"NO leap second will be introduced at the end of December 2026", 2017년 1월 1일부터 UTC−TAI = −37초
14IANA 시간대 자료(tzdb) asiaZone Asia/Seoul: 8:27:52 LMT ~ 1908-04-01, 8:30 ~ 1912-01-01, 9:00 ~ 1954-03-21, 8:30 ~ 1961-08-10, 9:00. Rule ROK 1987·1988 서머타임

출처 확인일 2026-10-18. 시간대 자료는 해마다 여러 번 고쳐지며, 화면의 시각은 쓰는 브라우저에 들어 있는 판을 따릅니다.

자주 묻는 질문

지금 유닉스 타임스탬프는 몇인가요?

맨 위 '지금 유닉스 시간' 띠가 이 기기 시계를 기준으로 1초마다 보여 줍니다. 2026년 10월 무렵에는 17억 9천만 초대의 10자리 숫자이고, 밀리초로는 끝에 세 자리가 더 붙은 13자리입니다. '초 복사'·'밀리초 복사'로 누른 순간의 값을 바로 복사할 수 있습니다.

1704067200은 몇 년 몇 월 며칠인가요?

2024년 1월 1일 00:00:00 UTC입니다. 한국 시각으로는 같은 날 오전 9시(월요일)입니다. 13자리 1704067200000은 같은 순간을 밀리초로 적은 값입니다.

10자리와 13자리 타임스탬프는 무엇이 다른가요?

요즘 날짜라면 10자리는 초, 13자리는 밀리초입니다. 같은 순간의 밀리초 값은 초 값의 1,000배입니다. 16자리는 마이크로초, 19자리는 나노초입니다. 10자리를 밀리초로 읽으면 1970년 1월로, 13자리를 초로 읽으면 수만 년 뒤로 나오니 날짜가 이상하면 단위부터 확인하세요.

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

날짜 칸에 날짜와 시각을 넣고 시간대를 '서울'로 두면 숫자 칸에 초가 나옵니다. 2024년 1월 1일 00:00:00(한국)은 9시간을 뺀 UTC 2023년 12월 31일 15:00이라 1704034800초입니다.

엑셀에서 유닉스 시간을 날짜로 바꾸는 식은 무엇인가요?

A1에 초가 있으면 =A1/86400+DATE(1970,1,1)이 UTC 날짜이고, 한국 시각은 끝에 +9/24를 더합니다. 밀리초면 86400 대신 86400000으로 나눕니다. 결과 칸의 서식을 날짜·시간으로 바꿔야 날짜로 보입니다.

2038년 문제는 무엇인가요?

초를 부호 있는 32비트 정수에 저장하면 2,147,483,647(2038년 1월 19일 03:14:07 UTC, 한국 낮 12시 14분 7초)이 가장 큰 값이라 그 뒤 시각을 담지 못하는 문제입니다. 64비트 정수로 저장하면 생기지 않습니다.

음수 타임스탬프도 있나요?

네. 1970년 1월 1일 0시(UTC) 이전 순간은 음수입니다. −1은 1969년 12월 31일 23:59:59 UTC이고, 부호 있는 32비트 최솟값 −2,147,483,648은 1901년 12월 13일 20:45:52 UTC입니다.

유닉스 시간에 윤초가 들어가나요?

아니요. POSIX 표준은 하루를 정확히 86,400초로 셉니다. 1972년 이후 UTC에 윤초가 27번 들어갔지만 유닉스 시간에는 23:59:60을 나타내는 숫자가 없어서, 2016년 12월 31일 23:59:59(1483228799) 다음 값 1483228800이 바로 2017년 1월 1일 0시입니다.

옛날 한국 날짜는 왜 UTC+9가 아닌 차이로 나오나요?

한국은 1954~1961년에 UTC+8:30을 썼고 1987·1988년 여름에는 서머타임(UTC+10)을 했습니다. 이 변환기는 IANA 시간대 자료로 그 날짜에 실제로 쓰던 차이를 반영합니다. 1908년 4월 전은 서울의 지방 평균시(UTC+8:27:52)입니다.

마이크로초·나노초 값도 바꿀 수 있나요?

네. 16자리는 마이크로초, 19자리는 나노초로 자동 판별하고 나노초까지 정확한 정수로 계산합니다. 자바스크립트의 보통 숫자(Number)는 2⁵³보다 큰 정수를 정확히 담지 못해 나노초 값의 끝자리가 바뀌지만, 이 변환기는 큰 정수(BigInt) 계산을 씁니다.