타임스탬프 변환
Unix 타임스탬프를 읽을 수 있는 날짜로, 또는 그 반대로 변환합니다. 초·밀리초·ISO 8601·UTC·현지 시각·요일·RFC 2822·"3시간
Unix 타임스탬프와 읽을 수 있는 날짜를 양방향으로, 그리고 초와 밀리초 단위로 모두 변환합니다. 1735689600 또는 2026-01-01T00:00:00Z를 붙여 넣으면 UTC, 현지 시간대, 그리고 ISO 8601과 RFC 2822 같은 일반적인 형식의 값을 확인할 수 있습니다.
로그를 읽을 때, 에포크 초를 반환하는 API를 디버깅할 때, 토큰 만료 시각이 생각한 대로인지 확인할 때 끊임없이 쓰입니다. 변환은 정확하고 기기 안에서 실행되며, 값이 초가 아니라 밀리초로 보일 때 경고해 줍니다.
Unix 타임스탬프를 변환하는 방법
타임스탬프 또는 날짜를 붙여 넣습니다
UTC와 현지 시간으로 변환된 값을 확인합니다
필요한 형식을 복사합니다
자주 묻는 질문
초인가요, 밀리초인가요?
10자리면 보통 초이고 13자리면 보통 밀리초입니다. 도구가 단위를 추정하며 결과가 이상하면 직접 바꿀 수 있습니다.
Unix 에포크란 무엇인가요?
1970년 1월 1일 00:00:00 UTC 이후의 초를 센 값이며 윤초는 세지 않습니다. 특정 시점을 저장하는 표준 방식입니다.
어떤 시간대를 쓰나요?
UTC와 브라우저의 현지 시간대를 모두 보여 주므로 서버 로그와 시계에서 보이는 시각을 비교할 수 있습니다.
1970년 이전 날짜도 다루나요?
네. 음수 값은 에포크 이전 날짜를 나타내며, 먼 미래 날짜도 JavaScript 날짜 범위의 한계까지 동작합니다.
날짜로부터 타임스탬프를 만들 수 있나요?
네. 변환은 양방향이므로 날짜를 입력하면 에포크 값을 얻습니다.
무엇인가 업로드되나요?
아니요. 변환은 기기 안의 계산으로만 끝납니다.
한눈에 보기
| 입력 | 텍스트 |
|---|---|
| 여러 파일 | 아니요 |
| 실행 위치 | 브라우저에서 실행 - 파일은 업로드되지 않습니다 |
| 오프라인에서도 작동 | 예 — 페이지를 불러온 후 |
| 가격 | 무료, 가입 필요 없음, 워터마크 없음 |
변환이 조용히 깨지는 곳
변환 버그는 대부분 문법이 아니라 의미의 문제입니다. 우편번호 CSV 열은 스프레드시트가 숫자라고 추측하는 순간 앞의 0을 잃습니다. 긴 ID는 부동소수점 정밀도를 넘어섭니다. 날짜는 일이 먼저인지 월이 먼저인지에 따라 의미가 달라집니다. JSON 키에는 순서가 없지만 배열에는 있습니다. 키를 정렬하는 도구는 아무것도 바꾸지 않지만 배열을 정렬하는 도구는 데이터를 바꿉니다. Unicode도 함정입니다. 텍스트는 UTF-8이나 UTF-16으로, 또는 BOM과 함께 도착할 수 있고, 잘못 추측한 디코더는 강세 문자가 있는 글자를 깨진 문자로 만듭니다. 어떤 변환이든 믿기 전에 첫 행과 마지막 행, 앞에 0이 붙은 필드, 따옴표나 쉼표, 줄바꿈이 들어 있는 필드를 표본 검사하십시오.
데이터 형식 고르기
JSON은 API가 반환하거나 프로그램이 읽는 데이터의 기본 선택입니다. 중첩 구조, 숫자, 불리언, null을 자연스럽게 다루고 모든 언어가 파싱합니다. CSV는 더 작고 스프레드시트에서 바로 열리지만, 중첩을 표현할 방법이 없고 구분자, 인용, 문자 집합에 관한 공통 표준도 없습니다. 변환이 어긋나는 지점이 바로 여기입니다. XML은 장황하지만 속성, 혼합 콘텐츠, 스키마를 담을 수 있어 문서 형식과 기존 연동에서 여전히 주류입니다. YAML은 설정 파일에 가장 읽기 좋지만 공백에 민감하고 형 변환이 뜻밖의 결과를 냅니다("no"가 false가 되거나 1.10 같은 버전이 1.1이 됩니다). 보기 좋은 형식이 아니라 그것을 사용하는 도구가 선호하는 형식을 고르십시오.