Skip to content
서버전송 없음 · 브라우저 처리

타임스탬프 변환

유닉스 타임스탬프(초·밀리초)와 날짜를 상호 변환해요.

지금:

즐겨찾기하면 홈에서 바로 찾을 수 있어요

이럴 때 쓰세요

1786147200 → 2026-08-05 09:00:00
로그의 13자리 밀리초 값을 사람이 읽는 시각으로
날짜를 초 단위 스탬프로 바꿔 API에 전달

이렇게 사용하세요

11단계스탬프 → 날짜 항목을 입력하세요
22단계값을 바꾸면 결과가 바로 갱신돼요
33단계변환 버튼으로 결과를 저장하거나 복사할 수 있어요

결과가 예상과 다를 때

결과가 예상과 달라요

단위와 기준을 먼저 확인해 주세요. 값을 바꾸면 결과가 바로 갱신돼요.

처음 값으로 되돌리고 싶어요

초기화를 누르면 처음 상태로 돌아가요.

자주 하는 실수

계산 근거

유닉스 에포크는 1970년 1월 1일 00시 00분 00초 UTC를 기준으로 지나온 시간을 셉니다. 초 단위 값은 32비트 부호 있는 정수 범위에 걸려 2038 문제를 일으키며, 그래서 밀리초 단위 64비트가 널리 쓰입니다. 문자열 표기는 ISO 8601(기본 YYYYMMDD, 확장 YYYY-MM-DD)이나 인터넷 시각 표준 RFC 3339를 따르고, 한국은 UTC+09:00입니다.

실제로 계산해 보면

1768435200은 언제인가요?

2026년 1월 15일 00시 00분 00초 UTC, 한국 시간으로는 같은 날 오전 9시입니다. 초 값을 86,400으로 나눈 몫과 나머지를 이용하면 날짜와 시각을 따로 얻을 수 있습니다. 밀리초로 쓰려면 뒤에 세 자리 000을 붙입니다.

반대로 날짜를 스탬프로 바꾸면?

2026년 7월 4일 00시 00분(한국 시간)은 1783090800입니다. 시차를 빼고 싶은 입력에는 반드시 시간대를 붙이세요. 표기가 없으면 브라우저가 현지 시각으로 해석합니다.

13자리 값이 왜 흔한가요?

자바스크립트의 Date.now()가 기본값으로 밀리초를 내기 때문에 값이 1,786,145,200,000처럼 13자리가 됩니다. 자릿수만 보고 단위를 알 수 있으니 10자리(초)와 13자리(밀리초)를 헷갈리지 않게 따로 적어 두면 안전합니다.

더 궁금한 것

서머타임이 있는 국가에서는 값이 틀리나요?

값 자체는 틀리지 않습니다. 에포크는 UTC를 기준으로 하므로 서머타임이 있는 나라도 같은 숫자를 냅니다. 다만 사람을 읽는 날짜로 되돌릴 때 현지 시각 규칙(서머타임 시각)을 따라야 해서, 국가·연도를 함께 적어 두는 편이 좋습니다.

범위를 벗어난 값은 어떻게 되나요?

지나치게 크거나 작은 값을 넣으면 날짜가 1970년 이전이나 수만 년 뒤로 튀어 나옵니다. 0은 에포크 자체(1970-01-01), 음수는 에포크 이전을 뜻하니 오류 데이터인지 먼저 확인하는 편이 좋습니다.

API 응답의 날짜 필드는 어떻게 읽나요?

응답에는 숫자 스탬프, ISO 문자열, 밀리초 값이 섞여 나옵니다. 필드 이름만 보고 넘기지 말고 값의 길이와 형식을 확인해 단위를 정하세요. 문자열에는 마지막에 Z(UTC)나 +09:00 같은 시간대가 붙는 경우가 많습니다.

알아둘 경계값

결과를 믿기 전 확인 목록

자주 묻는 질문

초와 밀리초 구분은?

10자리면 초, 13자리면 밀리초로 자동 판별합니다.

시간대는 어디 기준인가요?

브라우저의 로컬 시간대를 씁니다. 서버가 UTC라면 9시간 차이가 날 수 있으니 양쪽을 확인하세요.

관련 도구

전체보기 →