01
감지된 형식부터 보기
ISO 8601 날짜 변환은 완전한 RFC 3339 형식과 호환 입력을 구분합니다. 공백 구분자, 생략한 초 또는 +0900 오프셋은 분석할 수 있지만 이 도구의 RFC 3339 하위 집합으로 표시하지 않습니다.
날짜와 시간
ISO 8601 변환기시각과 실제 순간을 구분하세요
한 줄에 ISO 또는 RFC 날짜 하나를 입력하세요. 시간대가 없으면 기본적으로 미지정 상태를 유지합니다.
ISO 8601 변환기
입력
입력은 이 브라우저에서 처리되며 서버로 전송되지 않습니다.
결과
옵션
한 줄에 하나: 2024-01-01T08:00:00+08:00, 2024-01-01, 08:00 또는 Sun, 06 Nov 1994 08:49:37 GMT.
소수 초 최대 9자리. Unix 초·밀리초는 내림하고 나노초는 정확하게 보존합니다. HTTP 출력은 정수 초만 지원합니다.
최대 1000행, 전체 100000 UTF-16 코드 단위, 한 행 512개. 빈 행은 오류입니다.
입력하거나 예시를 불러오세요.
ISO 8601 변환기는 API 응답이나 서버 로그의 날짜가 왜 9시간 달라 보이는지 확인할 때 유용합니다. 표시된 시각만 비교하기 전에 각 문자열의 오프셋이 같은지, 실제 순간을 정할 정보가 있는지 살펴보세요.
원래 입력과 분석한 필드를 함께 남겨 날짜가 바뀐 이유를 추적할 수 있습니다. 없는 날짜를 다음 달로 넘겨 고치지 않으며, 잘못된 한 행 때문에 나머지 결과가 사라지지 않습니다.
ISO 8601 변환기로 확인할 수 있는 차이
다른 시각이 같은 순간인지 확인
ISO 8601 변환기는 같은 날의 08:00+08:00과 00:00Z를 서로 다른 원본 필드로 표시하면서 동일한 Unix 값을 계산합니다. UTC 변환 후 날짜나 시간이 바뀌어도 실제 순간이 유지되는지 확인할 수 있습니다.
없는 정보는 그대로 남기기
날짜만 있으면 자정을 넣지 않고, 시각만 있으면 오늘 날짜를 넣지 않습니다. UTC로 해석하도록 선택해도 날짜나 시각 자체가 빠진 값을 완전한 타임스탬프로 바꾸지는 않습니다.
비교 전에 확인할 세 가지
02
UTC 가정을 명시적으로 선택하기
시간대가 없는 완전한 날짜와 시각에만 UTC 가정을 적용할 수 있습니다. 출처가 불분명하면 미지정 상태를 유지하세요. 이미 입력된 오프셋은 설정에 상관없이 우선하며, 선택한 가정은 보고서에 남습니다.
03
경고와 갱신 시점 확인하기
자동 분석은 편집 후 350ms 뒤 실행됩니다. 끄면 버튼이나 Ctrl/Cmd + Enter로 실행하세요. 수정 즉시 이전 결과의 내보내기가 비활성화됩니다. 화면은 50행씩 늘어나지만 복사와 저장에는 모든 행이 들어갑니다.
원본 필드에서 비교 가능한 값까지
실제 달력 날짜 검사
날짜 시간 파싱 과정에서 윤년을 포함한 연월일 조합을 검사합니다. 2월 30일을 3월로 넘기거나 잘못된 시분초를 보정하지 않아 원본의 오류를 드러냅니다.
메일 날짜와 요일 검증
RFC 2822/5322의 명시된 하위 집합을 처리합니다. 영문 월, 숫자 오프셋 및 GMT/UT를 사용할 수 있고, 요일이 있으면 날짜와 일치해야 합니다. HTTP의 고정 형식은 메일 호환 형식과 구분합니다.
나노초까지 보존
소수 초는 최대 9자리까지 그대로 유지하며 UTC는 9자리로 표시합니다. Unix 나노초는 정확한 정수 문자열입니다. 초와 밀리초는 내림하므로 1970년 이전의 음수도 0 방향으로 잘리지 않습니다.
HTTP 출력의 정밀도 조건
UTC 연도가 1900–9999이고 소수 초가 0인 순간만 IMF-fixdate로 출력합니다. 헤더를 만들려고 소수 부분을 버리지 않으며, 정확한 ISO 결과와 출력 불가 이유를 함께 남깁니다.
지원 범위와 추측하지 않는 값
- 시간대 없는 입력
- 기본 설정은 UTC, Unix, HTTP를 계산하지 않습니다. 완전한 날짜와 시각이라면 사용자가 UTC로 해석하도록 선택할 수 있습니다. 날짜 전용 및 시각 전용 값에는 빠진 부분을 채우지 않습니다.
- ISO 전체 규격은 아님
- YYYY-MM-DD와 HH:mm[:ss[.fraction]]을 T, t 또는 공백 하나로 연결할 수 있습니다. Z/z 및 ±HH:MM, ±HHMM을 지원합니다. 원본과 UTC 연도는 0001–9999이며, 기본 형식·주 날짜·서수 날짜·기간·구간은 받지 않습니다.
- 범위를 넘으면 오류
- 시는 00–23, 분과 초는 00–59, 소수 초는 최대 9자리입니다. 24:00, 윤초, 소수 쉼표는 거부합니다. 음의 0 오프셋은 원래 지역 오프셋이 불명이라는 뜻을 유지하면서 UTC 순간은 계산합니다.
- 제한된 RFC 구문
- 1900년부터의 네 자리 연도와 영문 월을 사용합니다. 주석, 접힌 헤더, 두 자리 연도, GMT/UT 이외의 시간대 약어 및 구형 HTTP 날짜는 지원하지 않습니다. 요일이 제공되면 반드시 일치해야 합니다.
- 배치 크기와 입력 경로
- 최대 1000행, 전체 100000 UTF-16 코드 단위, 한 행 512개입니다. 빈 행은 오류로 남습니다. 파일·URL 가져오기, 숫자 타임스탬프 입력, 지역 시간대·서머타임 변환과 모호한 슬래시 날짜 추정은 제공하지 않습니다.
ISO 8601 변환기 자주 묻는 질문
끝의 Z와 +09:00은 무슨 차이인가요?
Z는 UTC 오프셋이 0이라는 뜻이고, +09:00은 UTC보다 9시간 앞선 시각 표현입니다. 같은 날의 09:00+09:00과 00:00Z는 같은 순간입니다. 어느 지역에서 생성되었는지는 오프셋만으로 알 수 없습니다.
ISO 8601과 RFC 3339는 같나요?
ISO 8601에는 여러 날짜 및 시간 표현이 있습니다. RFC 3339는 인터넷 타임스탬프를 위한 형식입니다. 이 페이지는 그중 지원하는 구문을 명시하고 윤초처럼 처리하지 않는 경우도 구분합니다.
변환한 날짜가 왜 9시간 어긋나나요?
원본이 +09:00인데 결과가 UTC라면 시각에서 9시간을 빼는 것이 맞습니다. 문자열 끝의 오프셋을 확인하세요. 시간대가 없던 값이라면 출처를 알아야 하며, 이 도구는 브라우저 시간대로 추정하지 않습니다.
2038년 문제는 무엇인가요?
Unix 초를 부호 있는 32비트 정수에 저장하는 시스템은 2038년에 범위를 넘습니다. 이 도구의 정수 문자열 계산에는 그 제한이 없지만, 내보낸 값을 저장할 대상 시스템의 자료형과 범위는 별도로 확인해야 합니다.
API나 데이터베이스에는 어떤 형식을 써야 하나요?
사용할 API 또는 데이터베이스의 명세를 따르세요. UTC ISO 값은 순간을 비교하기에 편리하지만 허용하는 소수 초 자릿수는 다를 수 있습니다. 날짜만 필요한 필드를 무조건 타임스탬프로 바꾸지는 마세요.
예상과 다른 결과인가요?