본문으로 건너뛰기
yutils
예시

입력

1715600000

출력 (양방향 동시)

Unix (초):     1715600000
Unix (밀리초): 1715600000000
ISO 8601:      2024-05-13T13:33:20.000Z
UTC:           Mon, 13 May 2024 13:33:20 GMT
로컬:          2024-05-13 22:33:20 (KST)

참고

입력이 10자리면 초, 13자리면 밀리초로 자동 인식. 날짜 문자열도 ISO 8601 / RFC 2822 / 자유 형식까지 다 받습니다.

사용법 / 자주 묻는 질문

이런 경우 사용하세요

  • API 응답의 Unix 타임스탬프(JWT exp, MongoDB ObjectId 시간부 등)를 사람이 읽을 수 있게
  • DB log 의 epoch 시간을 KST 변환
  • 현재 시각의 timestamp 가 필요할 때 (now 버튼)
  • ISO 8601 ↔ epoch 변환 — 둘이 헷갈리는 환경 디버깅
  • 타임존 영향 받지 않는 절대 시각 표현

자주 묻는 질문

Q.초와 밀리초를 어떻게 구분하나요?
A.자릿수로 자동 추론 — 10자리 = 초, 13자리 = 밀리초가 표준. JavaScript Date 는 ms 기반, Unix / Python time.time() 은 초가 기본. 헷갈릴 때 가장 흔한 1000x 오류.
Q.Y2K38 문제가 뭔가요?
A.32-bit signed int 의 한계 — 2038년 1월 19일 03:14:07 UTC 에 overflow. 64-bit timestamp (현재 표준) 으로 약 2900억년 후까지 안전.
Q.timestamp 가 음수면?
A.1970-01-01 이전 시각 — 음수 epoch. 예: -86400 = 1969-12-31. 일부 legacy 시스템은 음수 timestamp 를 처리 못 하니 주의.
재미있는 사실

  • 1970-01-01 00:00:00 UTC 가 Unix epoch — Bell Labs 가 PDP-11 시스템을 만들 때 정한 기준점입니다. 실제로는 첫 Unix Programmer's Manual(1971-11)이 1971-01-01 epoch 를 썼다가 1970 으로 변경한 흔적이 있습니다.

    Wikipedia — Unix time

  • 2038-01-19 03:14:07 UTC — 32비트 signed integer 가 overflow 하는 순간. Y2K 의 후계자라 'Year 2038 problem' 으로 불리며, 임베디드·DB int32 컬럼에 아직 많이 남아있어 실제 위협으로 남아있습니다. 64비트 시간은 약 2,920억 년 뒤에야 한계.

    Y2038 problem

  • Unix time 은 윤초(leap seconds)를 무시합니다. UTC 와 Unix time 의 차이는 윤초 누적분 — 2025 년 현재 27 초 — 만큼 벌어져 있고, 윤초가 발생한 날의 UTC 23:59:60 은 Unix time 에서는 같은 초가 두 번 반복되는 식으로 표현됩니다.

    Wikipedia — Leap second

관련 도구

이 카테고리 모든 도구 보기 →