날짜·시간 워크벤치 | ISO 8601과 Unix Cron 검사

텍스트브라우저에서 실행(업로드 없음)

명시적인 ISO 8601 instant를 선택한 IANA 시간대에 맞춰 표시하거나, 표준 5필드 Unix cron 표현식을 정규화된 필드와 DST가 반영된 다음 실행 시각으로 검사합니다. 오프셋 없는 모호한 날짜, 6필드 일정, Quartz 확장자, 잘못된 범위와 자원 한도 초과는 추측하지 않고 거부합니다. 처리는 브라우저 안에서 이루어집니다.

다음에 할 작업

관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.

이 도구 사용 방법

정확한 instant 하나를 비교하려면 Date formats를, 반복되는 5필드 Unix 표현식을 검증하려면 Cron schedule을 선택합니다. 스케줄러 문서 없이 6필드나 Quartz 표현식을 다른 방언으로 옮기지 마세요.

Date 모드에서 Z 또는 명시적인 숫자 오프셋이 있는 ISO 8601 날짜·시간을 입력하고 표시할 IANA 시간대를 선택합니다. 오프셋 없는 로컬 시각은 의도적으로 거부됩니다.

포맷을 실행해 UTC ISO, 선택 시간대 RFC 3339, HTTP date, Unix seconds와 milliseconds를 비교합니다. 표시 시간대만 바꿨을 때 Unix 값이 그대로인지 확인하세요.

Cron 모드에서 분, 시, day-of-month, 월, day-of-week를 입력하고 명시적인 ISO 기준 시각과 IANA 시간대를 선택한 뒤 다음 3회, 5회 또는 10회를 계산합니다.

원문과 정규화 필드를 비교하고 날짜 필드 OR 및 오프셋 변경 경고를 읽습니다. 특히 DST 경계에서 모든 다음 실행을 선택 시간대와 UTC 양쪽으로 확인하세요.

증거를 복사하거나 다운로드한 뒤 실제 운영 스케줄러에서 표현식을 시험하고, 활성화 전에 방언, 시간대 설정, 중복·누락 실행과 배포 정책을 문서화합니다.

이 도구를 써야 할 때

여러 시스템의 장애 시각 연결

로그, API payload와 지원 티켓의 타임스탬프를 UTC ISO와 Unix milliseconds로 맞춰 세 시스템이 같은 장애를 기록했는지 확인합니다.

모호하지 않은 릴리스 시각 게시

하나의 Unix 값을 유지한 채 릴리스 instant를 UTC, 서울, 런던 또는 뉴욕으로 표시해 배포 계획과 검토 기록에 사용합니다.

배포 전 예약 작업 검토

다음 DST 전환을 포함해 평일 또는 월간 cron 실행을 확인하고 운영 일정을 바꾸기 전에 로컬 벽시계와 UTC를 비교합니다.

Pull request의 cron 표현식 감사

이름 필드를 정규화하고 day-of-month/day-of-week OR 규칙을 드러내 코드 리뷰에서 추측이 아닌 실제 Unix 일정을 논의합니다.

서비스 시간대 이전 계획

두 IANA 시간대 후보의 오프셋과 다음 실행 순서를 비교하면서 catch-up과 중복 실행 규칙은 별도 운영 시험이 필요하다고 기록합니다.

흔한 실수

오프셋 없는 날짜·시간을 전역 instant로 취급하기

2026-07-16T09:30:00 같은 값에는 오프셋이 없어 컴퓨터마다 서로 다른 instant를 뜻할 수 있습니다. 시스템을 비교하기 전에 Z 또는 +09:00 같은 명시적 오프셋을 붙이세요.

표시 변환과 실제 이벤트 시각 변경을 혼동하기

표시 시간대를 바꿔도 underlying instant는 바뀌면 안 됩니다. 시간대를 바꾸기 전후의 UTC ISO와 Unix milliseconds가 같은지 확인하고 달력 표기와 오프셋만 달라지는지 보세요.

5필드 Unix cron과 6필드 방언 섞기

Unix cron은 보통 분으로 시작하는 5필드 형식이지만 Quartz 같은 스케줄러는 초 필드와 다른 특수 토큰을 사용합니다. 유효해 보이도록 필드를 지우지 말고 운영 스케줄러 방언을 먼저 확인하세요.

두 cron 날짜 필드를 AND로 해석하기

Vixie 계열 cron에서 day-of-month와 day-of-week가 모두 제한되면 보통 OR로 일치합니다. 0 0 1 * MON은 월요일이면서 1일일 때만이 아니라 모든 월요일 또는 매월 1일에 실행될 수 있습니다.

DST 전환 밖의 날짜만 테스트하기

UTC에서 정상으로 보이는 일정도 DST 전환 때 로컬 벽시계 한 시간을 건너뛰거나 반복할 수 있습니다. 운영과 같은 IANA 시간대와 스케줄러로 다음 전환을 포함한 여러 실행 시각을 확인하세요.

예시

서울 배포 타임스탬프 정규화

+09:00 오프셋이 하나의 instant를 확정합니다. UTC는 00:30:15.250Z가 되고 서울 표시는 09:30:15.250+09:00으로 유지됩니다.

입력
2026-07-16T09:30:15.250+09:00, Asia/Seoul
출력
UTC ISO, 서울 RFC 3339, HTTP date, 지역화 문자열, Unix seconds와 milliseconds

일광 절약 시간 전환 확인

DST 경계의 두 UTC instant가 01:59 -05:00과 03:01 -04:00으로 표시됩니다. 존재하지 않는 로컬 02시가 숨겨지지 않습니다.

입력
2026-03-08T06:59:00Z와 2026-03-08T07:01:00Z, America/New_York
출력
봄철 시계 이동 전후 서로 다른 UTC 오프셋을 가진 RFC 3339 값 두 개

HTTP 장애 기록용 시각 준비

HTTP 로그 시각을 UTC ISO와 Unix 값으로 함께 비교합니다. toUTCString 결과를 RFC 2822라고 잘못 부르지 않고 HTTP date로 구분합니다.

입력
2026-01-15T18:45:00Z, Europe/London
출력
Thu, 15 Jan 2026 18:45:00 GMT와 동일한 ISO·epoch 값

DST를 가로지르는 평일 오전 작업 검증

5개 필드는 0분, 9시, 모든 날짜와 월, 월요일부터 금요일을 선택합니다. 각 다음 실행은 해당 날짜 뉴욕의 실제 오프셋을 반영합니다.

입력
0 9 * * 1-5, 2026-03-06T15:00:00Z 이후, America/New_York
출력
DST 시작 뒤 2026-03-09T09:00:00-04:00을 포함한 평일 오전 9시 다음 5회

이름으로 쓴 cron 필드 정규화

월과 요일 영문 별칭을 받아 숫자 필드로 정규화하므로 원문과 parser 계약을 나란히 비교할 수 있습니다.

입력
15 8 * JAN MON, 2025-12-31T00:00:00Z 이후, UTC
출력
15 8 * 1 1로 정규화되고 첫 실행은 2026-01-05T08:15:00Z

모호하게 보이는 날짜 일정 드러내기

두 날짜 필드가 모두 제한되어 다음 실행 결과와 함께 Unix/Vixie OR 규칙 경고를 표시합니다.

입력
0 0 1 * MON, 2026-01-01T00:00:00Z 이후, UTC
출력
필드 표, 다음 실행 표, day-of-month/day-of-week OR 경고

엄격한 instant, IANA 달력 표시와 제한된 Unix cron 반복 계산

날짜 파싱은 브라우저의 관대한 Date 문자열 파서를 호출하지 않습니다. 엄격한 parser가 그레고리력 연도, 월 길이, 윤일, 시각 필드, 최대 세 자리 소수와 필수 Z 또는 ±HH:mm 오프셋을 검사합니다. 검증한 로컬 구성 요소를 하나의 Unix millisecond instant로 만든 뒤 표시 포맷을 적용합니다.

선택 시간대 값은 브라우저의 Intl 구현과 IANA 시간대 데이터를 사용합니다. 그레고리력과 라틴 숫자로 달력 부분을 재구성하고 해당 instant의 실제 오프셋을 계산해 RFC 3339를 조립합니다. 따라서 DST 오프셋 변화는 보이지만 UTC ISO와 Unix 값은 변하지 않습니다.

Cron 모드는 cron-parser를 동적으로 불러오고 정확히 5개 필드만 받습니다. 사전 검사는 일반 Unix 숫자, wildcard, 목록, 범위, 간격, 월·요일 별칭만 허용하고 macro, 초, Quartz ?, last-day L, nth-day #, hashed H를 거부합니다. 이후 parser가 범위를 검증하고 선택한 IANA 시간대의 다음 실행을 계산합니다.

day-of-month와 day-of-week가 모두 제한되면 그럴듯하지만 오해하기 쉬운 자연어 문장 대신 Unix/Vixie OR 규칙을 경고합니다. 반환된 실행 사이에서 UTC 오프셋이 달라져도 알립니다. 계산은 최대 10회와 8년으로 제한되며 재시도, 동시 실행, 누락 실행과 시스템 시계 정책을 시뮬레이션하지 않습니다.

날짜 입력은 Unicode 128 code points와 UTF-8 256 bytes, cron은 256 code points와 512 bytes, 시간대 이름은 128 code points, 출력은 262,144 bytes로 제한합니다. 정상 처리는 원문이나 결과를 애플리케이션 요청으로 보내지 않으며, 동의한 분석에도 입력 instant, 표현식, 기준 시각, 생성 일정은 포함하지 않습니다.

자주 묻는 질문

어떤 날짜 입력을 지원하나요?

Date 모드는 YYYY-MM-DDTHH:mm, 선택적인 초와 최대 세 자리 소수, 그리고 Z 또는 숫자 오프셋을 요구합니다. 날짜만 있는 값, 오프셋 없는 로컬 시각, 존재하지 않는 날짜, 윤초, 0001-9999 밖의 연도, ±14:00을 넘는 오프셋은 거부합니다.

RFC 3339와 HTTP date를 왜 구분하나요?

RFC 3339는 명시적 오프셋을 가진 인터넷 날짜·시간 프로필로 선택 시간대 결과에 사용됩니다. HTTP date는 Thu, 16 Jul 2026 00:30:15 GMT 같은 HTTP 헤더용 GMT 형식입니다. 서로 다른 프로토콜이므로 따로 표시합니다.

어떤 cron 방언을 지원하나요?

분, 시, day-of-month, 월, day-of-week 순서의 표준 5필드 Unix/Vixie cron을 지원합니다. 숫자, *, 목록, 범위, 간격과 영문 월·요일 별칭을 사용할 수 있습니다. macro, 초 필드, ?, L, #, H와 Quartz 동작은 거부합니다.

시간대와 DST는 어떻게 처리하나요?

선택한 IANA 시간대를 cron-parser에 전달해 시간대와 DST 규칙이 반영된 실행 시각을 계산합니다. 표에는 각 결과의 RFC 3339 로컬 시각과 UTC를 함께 표시합니다. catch-up, 중복 실행, 재부팅, 배포 정책은 표현식 계산 밖이므로 실제 스케줄러를 별도로 시험해야 합니다.

처리 한도는 어떻게 되나요?

날짜 입력은 Unicode 128자와 UTF-8 256 bytes, cron 입력은 256자와 512 bytes입니다. 한 번에 최대 10회를 8년 탐색 범위에서 계산하고 출력은 262,144 bytes로 제한합니다. IANA 이름은 128자까지입니다.

날짜나 cron 표현식을 업로드하나요?

아닙니다. 일반 날짜 포맷과 일정 검사는 브라우저 로컬에서 실행되고 cron-parser는 Cron 모드를 실행할 때만 불러옵니다. 동의한 분석에는 상위 도구, 모드, 선택 IANA 시간대, 실행 횟수, byte 수, 처리 시간과 경고 합계만 들어갈 수 있으며 날짜, 표현식, 기준 시각과 결과 본문은 포함하지 않습니다.

이 도구를 검증한 방법

관리 및 검수 검토일

검증 방법: 이번 검증은 “2026년 뉴욕 spring-forward를 가로지르는 평일 작업 검증”의 정확한 입력과 날짜·시간 워크벤치를 짝지어 수행했습니다. “정확한 스케줄러 방언과 실행 소유자 확인” 단계를 거쳐 “자연어 한 문장에 의존하지 않고 5개 필드 검사” 이후 결과를 캡처해 예시와 비교했습니다. 명시적인 경계 질문은 “오프셋 없는 티켓 시각을 기준점으로 사용”, “제한된 두 날짜 필드를 AND로 해석”였습니다.

기대 결과: 다음 평일 실행은 America/New_York의 2026-03-09 09:00, UTC 13:00으로 계산돼 spring-forward 이후 -04:00 offset을 정확히 적용했습니다.

검증한 작업 가이드 열기

관련 작업 가이드

도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.

관련 도구

관리 중인 다른 작업 흐름을 이어서 사용해 보세요

모든 도구 둘러보기