로그에 1755043200 이라고만 찍혀 있으면 그게 언제인지 알 수 없습니다. Unix 타임스탬프는 1970년 1월 1일 UTC 자정부터 흐른 시간을 숫자 하나로 표현한 값이라 기계에게는 편하지만 사람에게는 읽히지 않습니다. 이 도구는 그 숫자를 사람이 읽는 날짜로 바꾸고, 반대 방향으로도 변환합니다.
단위를 자릿수로 자동 판별하는 점이 실무에서 특히 유용합니다. 같은 시점이라도 초 단위면 10자리, 밀리초면 13자리, 마이크로초면 16자리, 나노초면 19자리가 됩니다. 자바스크립트는 밀리초를, 파이썬과 유닉스 계열은 초를, 데이터베이스와 관측 도구는 마이크로·나노초를 쓰는 경우가 많아 섞이기 쉬운데, 붙여넣기만 하면 알아서 맞춰 해석합니다.
사용 방법
- 타임스탬프나 날짜 붙여넣기 — 입력창에 숫자를 넣으면 날짜로,
2026-08-13T00:00:00Z같은 날짜 문자열을 넣으면 타임스탬프로 변환합니다.2026/08/13 09:00처럼 슬래시를 쓴 형식도 인식합니다. 입력을 비워 두면 현재 시각이 1초마다 갱신되며 표시됩니다. - 단위 확인하기 — 기본값인 자동 감지는 자릿수로 단위를 추론합니다. 의도한 것과 다르게 해석됐다면 초·밀리초·마이크로초·나노초를 직접 지정하세요. 1970년 근처의 아주 작은 값을 다룰 때는 자동 감지가 헷갈릴 수 있으므로 직접 지정하는 편이 안전합니다.
- 필요한 형식 복사하기 — 결과 표에 Unix 초·밀리초, ISO 8601, 내 지역 시각, UTC, RFC 2822가 함께 나옵니다. 각 줄 오른쪽 복사 버튼으로 필요한 형식만 가져가면 됩니다. ISO 8601은 API 요청에, RFC 2822는 이메일 헤더에 주로 쓰입니다.
- 다른 타임존에서 확인하기 — 맨 아래에서 타임존을 고르면 같은 시점이 그 지역에서 몇 시인지 보여 줍니다. 해외 팀과 장애 시각을 맞춰 볼 때나, 특정 지역 사용자의 로그를 그 사람의 현지 시각으로 읽어야 할 때 씁니다.
자주 묻는 질문
10자리와 13자리는 왜 생기나요?
같은 시점을 초로 세느냐 밀리초로 세느냐의 차이입니다. 2001년 9월 이후의 시각은 초 단위로 10자리, 밀리초 단위로 13자리가 됩니다.
이 차이 때문에 생기는 대표적인 버그가 '1970년으로 표시되는 날짜'입니다. 밀리초 값을 초로 잘못 해석하면 1970년 근처의 값이 나오고, 반대로 초 값을 밀리초로 해석하면 5만 년 후가 됩니다. 화면에 엉뚱한 연도가 뜬다면 1000을 곱하거나 나눠야 하는지 먼저 확인해 보세요.
2038년 문제가 무엇인가요?
타임스탬프를 부호 있는 32비트 정수로 저장하는 시스템은 2038년 1월 19일 03:14:07 UTC를 넘기면 값이 넘쳐 음수가 됩니다. 그러면 1901년으로 표시되는 오작동이 발생합니다.
요즘 만드는 시스템은 대부분 64비트를 쓰므로 실질적인 걱정거리는 아닙니다. 다만 오래된 임베디드 기기, 낡은 C 코드, MySQL의 TIMESTAMP 컬럼(범위가 2038-01-19까지)에는 여전히 남아 있는 문제입니다. 만료일이 먼 미래인 데이터를 다룬다면 DATETIME 이나 64비트 정수를 쓰세요.
윤초는 반영되나요?
반영되지 않습니다. Unix 시간은 정의상 하루를 정확히 86,400초로 취급하며 윤초를 세지 않습니다. 윤초가 삽입되는 순간 시스템은 같은 타임스탬프를 두 번 쓰거나 시계를 조금씩 늦추는 방식으로 넘어갑니다.
대부분의 애플리케이션에서는 신경 쓸 필요가 없습니다. 다만 금융 거래 체결 순서나 분산 시스템의 이벤트 순서처럼 1초 미만의 정확성이 중요하다면, 타임스탬프 대신 논리 시계나 단조 증가 카운터를 쓰는 편이 안전합니다.
표시되는 시각이 제 컴퓨터 시간과 다릅니다.
'내 지역 시각' 줄은 브라우저가 알려 주는 타임존을 그대로 씁니다. 운영체제의 타임존 설정이 실제 위치와 다르거나, VPN·가상머신·도커 컨테이너 안에서 열었다면 그 설정을 따라갑니다.
화면 위쪽 '내 타임존' 카드에 브라우저가 인식한 타임존 이름이 표시되므로 먼저 그 값을 확인해 보세요. UTC로 나온다면 시스템 타임존이 설정되지 않은 환경일 가능성이 높습니다.
알아두면 좋은 개념
에포크가 1970년인 이유
1970년 1월 1일은 유닉스가 개발되던 시기와 가까워 선택된, 특별한 의미가 없는 기준점입니다. 초기 유닉스는 1/60초 단위로 시간을 셌는데 32비트로는 2년 반밖에 표현할 수 없어서, 단위를 초로 바꾸고 기준을 1970년으로 잡았습니다.
다른 시스템은 다른 기준을 씁니다. 윈도우 파일 시간은 1601년부터 100나노초 단위로, 엑셀은 1900년 1월 0일부터 하루 단위로 셉니다. 그래서 엑셀에서 내보낸 날짜 컬럼을 그대로 타임스탬프로 읽으면 엉뚱한 값이 나옵니다.
타임스탬프에는 타임존이 없다
자주 오해받는 부분입니다. Unix 타임스탬프는 항상 UTC 기준의 절대 시점이며 지역 정보를 담지 않습니다. 서울에서 만든 1755043200 과 뉴욕에서 만든 1755043200 은 완전히 같은 순간을 가리킵니다.
타임존은 그 숫자를 화면에 표시할 때만 개입합니다. 그래서 데이터베이스에는 타임스탬프나 UTC 시각으로 저장하고, 사용자에게 보여 줄 때만 그 사람의 타임존으로 변환하는 것이 원칙입니다. 지역 시각을 그대로 저장하면 서머타임 전환 시각에 같은 시각이 두 번 존재하거나 아예 존재하지 않는 구간이 생겨 버그의 원인이 됩니다.
ISO 8601을 기본으로 삼아야 하는 이유
2026-08-13T00:00:00Z 형식은 국제 표준이며, 문자열 그대로 정렬해도 시간 순서와 일치한다는 큰 장점이 있습니다. 로그 파일을 sort 로 정렬하기만 해도 시간순이 됩니다.
반면 08/13/2026 같은 형식은 미국식(월/일)과 유럽식(일/월)이 충돌해 3월 4일인지 4월 3일인지 알 수 없습니다. API를 설계할 때 날짜를 주고받는 형식은 ISO 8601로 통일하고, 끝의 Z(UTC) 또는 +09:00 같은 오프셋을 반드시 붙이세요. 오프셋이 없는 날짜 문자열은 받는 쪽이 제멋대로 해석합니다.