유닉스 타임스탬프 변환기
유닉스 시간(초·밀리초·마이크로초·나노초)과 날짜(RFC 3339)를 서로 바꿉니다.
입력한 값은 이 브라우저 안에서만 처리하고 서버로 보내거나 저장하지 않아요. 결과는 참고용입니다.
이렇게 쓰세요
- 방향을 고릅니다. 타임스탬프를 날짜로 보려면 "타임스탬프 → 날짜", 반대면 "날짜 → 타임스탬프"입니다.
- 입력 칸에 값을 넣습니다. 비워 두면 현재 시각을 사용하고 그 사실을 알려 줍니다.
- 타임스탬프의 단위는 "자동 판별"이 자릿수로 추정합니다. 추정이 틀렸다면 초·밀리초·마이크로초·나노초 중에서 직접 고르세요.
- 날짜를 입력할 때는 RFC 3339 형식(예: 2023-11-14T22:13:20Z)만 받습니다. 표시할 시간대는 목록에서 고릅니다.
- 결과 아래의 상세 표에서 같은 시각의 초·밀리초·마이크로초·나노초 값과 32비트 범위 안팎 여부를 확인합니다.
초·밀리초·마이크로초·나노초와 자릿수 판별
같은 시각이라도 프로그래밍 언어와 시스템마다 단위가 다릅니다. 이 도구는 입력한 값을 초·밀리초·마이크로초·나노초 중 하나로 읽고, 결과 표에는 네 단위 값을 모두 보여 줍니다. 예를 들어 1700000000(초)은 2023-11-14T22:13:20Z입니다.
단위 자동 판별은 정수 부분의 자릿수(앞의 0 제외)가 11자리 이하면 초, 12~14자리면 밀리초, 15~17자리면 마이크로초, 18자리 이상이면 나노초로 보는 이 도구의 휴리스틱입니다. 표준이 아닙니다. 그래서 1000000000000(12자리)은 밀리초로 읽히며, 초 단위 12자리 값이라면 단위를 "초"로 직접 골라야 합니다. 소수부는 단위에 따라 초 9자리, 밀리초 6자리, 마이크로초 3자리까지 받고 나노초는 소수를 받지 않습니다.
유닉스 시간·윤초·2038년
POSIX.1-2024 4.19는 하루를 정확히 86400초로 센다고 정합니다. 그래서 RFC 3339 §5.7이 허용하는 "초 = 60"(윤초)은 유닉스 시간으로 나타낼 수 없고, 이 도구는 이를 오류로 알립니다. 시험 값으로는 RFC 3339 §5.8의 윤초 예 1990-12-31T23:59:60Z를 씁니다.
부호 있는 32비트 정수의 범위는 −2147483648~2147483647입니다. 2147483647은 2038-01-19T03:14:07Z, 2147483648은 2038-01-19T03:14:08Z로 직접 계산해 확인했습니다. 이 도구는 이 경계를 "32비트 범위" 행에 안/밖으로 보여 주기만 하며, 실제 시스템이 어떤 크기의 정수를 쓰는지는 주장하지 않습니다.
1970년 이전이나 음수 값은 POSIX가 UTC 이름과의 관계를 "undefined"로 두고 있습니다. 이 도구는 그 영역을 ECMAScript 날짜 계산으로 처리합니다.
HTTP 날짜와 시간대 표시
결과의 HTTP 날짜는 RFC 9110 §5.6.7의 IMF-fixdate 형식입니다. 예를 들어 784111777은 Sun, 06 Nov 1994 08:49:37 GMT입니다. 연도가 4자리라서 0000~9999년만 표현되고, 소수 초는 버립니다.
선택한 시간대의 시각은 브라우저의 Intl.DateTimeFormat과 거기에 들어 있는 IANA 시간대 데이터로 계산합니다. 서머타임과 과거 오프셋은 브라우저 버전에 따라 최신 규칙과 다를 수 있습니다. 로컬 시간은 보는 사람의 브라우저 설정에 따라 달라지고, 연도가 1~9999 범위 밖이면 해당 시간대 출력은 비워 둡니다.
"2023-11-14 22:13" 같은 입력은 RFC 3339 date-time 형식(문법상 "T" 사용)이 아닙니다. RFC 3339 §5.6은 응용 프로그램이 가독성을 위해 공백을 쓸 수도 있다고만 언급하며, 이 도구는 T만 받으므로 날짜 형식 오류가 납니다. "2023년 11월 14일"도 마찬가지입니다.
자주 묻는 질문
유닉스 타임스탬프란 무엇인가요?
1970-01-01T00:00:00Z(에포크)부터 지난 시간을 세는 값입니다. POSIX는 하루를 항상 정확히 86400초로 세도록 정해 두었기 때문에 윤초는 이 값에 나타나지 않습니다. 예를 들어 0은 1970-01-01T00:00:00Z이고 1700000000은 2023-11-14T22:13:20Z입니다.
단위를 자동으로 판별하는 규칙은 무엇인가요?
정수 부분의 자릿수(앞의 0 제외)로 추정합니다. 11자리 이하는 초, 12~14자리는 밀리초, 15~17자리는 마이크로초, 18자리 이상은 나노초로 봅니다. 표준이 아니라 이 도구가 정한 규칙이어서 12자리 초 값처럼 어긋나는 경우가 있습니다. 그럴 때는 단위를 직접 고르세요.
2038년 문제는 무엇인가요?
부호 있는 32비트 정수가 담을 수 있는 마지막 초는 2147483647이고, 이는 2038-01-19T03:14:07Z입니다. 다음 초인 2147483648은 2038-01-19T03:14:08Z라서 이 범위를 넘습니다. 이 도구의 "32비트 범위" 행이 안(in)인지 밖(out)인지 보여 줍니다. 어떤 시스템이 32비트를 쓰는지는 이 도구가 판단하지 않습니다.
날짜를 "2023-11-14 22:13"처럼 입력하면 왜 오류가 나나요?
날짜 → 타임스탬프 방향은 RFC 3339의 date-time 형식(YYYY-MM-DDTHH:MM:SS, 소수부 선택, 끝에 Z 또는 ±hh:mm)만 받기 때문입니다. 공백 구분, 날짜만 쓴 값, "2023년 11월 14일", 11/14/2023처럼 뜻이 모호한 형식은 받지 않습니다. 소문자 t와 z는 RFC 3339가 허용하므로 받습니다. 구분자는 T만 받습니다(RFC 3339 §5.6은 응용 프로그램이 공백을 쓸 수 있다고 하지만 이 도구는 받지 않습니다).
1970년 이전(음수) 값이나 아주 먼 미래도 되나요?
됩니다. 다만 POSIX는 1970년 이전·음수 값과 UTC 이름의 관계를 정의하지 않습니다. 이 도구는 ECMAScript 날짜 계산(그레고리력을 과거로 연장)으로 계산합니다. 범위는 ECMAScript 시간값 한계인 ±8,640,000,000,000,000 밀리초이고, 표시는 연도 0000~9999만 가능합니다.
출처와 기준일
- RFC 3339 Date and Time on the Internet: Timestamps (2002)
5.6 date-time ABNF; 5.7 (leap second 60); 5.8 examples; Appendix A (ISO 8601 collected ABNF, informational, dur-* productions) · 2026-11-10 - RFC 9110 HTTP Semantics
5.6.7 Date/Time Formats (IMF-fixdate) · 2026-11-10 - ECMAScript Language Specification (Date objects, Time Values and Time Range)
21.4.1 Overview of Date Objects and Definitions of Abstract Operations: time value range -8,640,000,000,000,000 to 8,640,000,000,000,000 ms · 2026-11-10 - POSIX.1-2024 (IEEE Std 1003.1-2024) Base Definitions, 4.19 Seconds Since the Epoch
4.19 Seconds Since the Epoch · 2026-11-10
공식 원문을 직접 열어 확인한 날: 2026-11-10. 표준과 규격은 바뀔 수 있으니 중요한 작업 전에는 원문을 다시 확인하세요.