예약 날짜는 9월 1일인데 내보낸 데이터에는 8월 31일이 보입니다. 무조건 하루를 더하면 될까요? 그러면 다른 시간의 기록이 오히려 틀어질 수 있습니다. 먼저 저장한 값이 달력의 날짜인지, 특정 순간인지 확인해야 합니다.
생일과 접속 시각은 같은 자료형이 아닙니다.
생일·휴무일·마감일처럼 “그날”이 중요한 값은 보통 달력 날짜입니다. 반면 주문 접수 시각은 세계 어디에서 보아도 같은 순간을 가리켜야 합니다. 시각을 다른 시간대로 표시하면 날짜가 바뀌어도 같은 순간일 수 있습니다.
| 입력 | 의미 | 이 글의 처리 |
|---|---|---|
| 2026-09-01 | 달력 날짜 | 날짜 그대로 유지 |
| 2026-09-01T00:30:00+09:00 | 한국 시간의 특정 순간 | UTC로는 8월 31일 15:30 |
| 03/04/2026 | 월/일 순서가 불명확 | 추측하지 않고 보류 |
TRY IT HERE
내 입력은 날짜인가요, 시각인가요?
입력은 현재 탭에서만 처리되며 자동 수정되지 않습니다. 실제 개인정보 대신 예제를 사용하세요.
최대 20만 자 · 원본 자동 수정 없음
세부 데이터·판정 규칙
하루가 바뀌어도 시간은 같을 수 있습니다.
한국: 2026-09-01 00:30:00 +09:00
UTC : 2026-08-31 15:30:00 Z두 줄은 같은 순간입니다. 다만 “9월 1일 마감”이라는 업무 규칙을 날짜로 저장하려던 것이라면 시각 변환을 거치지 않아야 합니다. 날짜 필드를 자정 시각으로 바꾼 다음 UTC 문자열 앞 10자리만 잘라 쓰는 방식이 흔히 혼란을 만듭니다.
모양이 맞는 것과 실제 날짜인 것도 다릅니다.
2026-02-29는 모양은 맞지만 달력에 없습니다. 2024-02-29는 있습니다. 이 검사기는 윤년과 월별 일수를 확인하고, 시간대가 빠진 2026-09-01T00:30:00은 자동 해석하지 않습니다. 실행하는 컴퓨터의 지역 설정에 따라 뜻이 달라질 수 있기 때문입니다.
반대로 “03/04”를 보았다고 무조건 3월 4일로 고치지 않습니다. 파일을 만든 나라·양식의 열 설명·원본 시스템을 확인하고, 알 수 없다면 미확인으로 남깁니다.
저장 규칙은 세 줄로 합의하세요.
- 날짜 필드는 YYYY-MM-DD로 두고 시간대 변환을 하지 않습니다. 이 규칙이 업무 의미와 맞는지 먼저 확인합니다.
- 시각 필드는 UTC 또는 명시적인 오프셋을 포함한 형식을 사용하고, 화면에 표시할 시간대를 별도로 정합니다.
- 원본 문자열과 정규화한 값을 함께 보관해 변환이 잘못됐을 때 되돌릴 수 있게 합니다.
국가별 공휴일, 영업일, 일광 절약 시간제의 업무 규칙까지 이 도구가 판정하지는 않습니다. 이 예제의 표시 시간대는 Asia/Seoul로 고정되어 있습니다.
이 글의 재현 자료
전체 자료의 범위·실행 방법·주의사항은 재현 자료 안내에서 한번에 확인할 수 있습니다.
원문과 함께 읽기
“날짜” 하나로 저장하지 않습니다.
| 사용자의 뜻 | 권장 형태 | 예 |
|---|---|---|
| 날만 중요 | YYYY-MM-DD 문자열 | 생일·영업일 |
| 지역 시각 | 지역별 날짜+시간대 | 회의·예약 |
| 순간 | UTC 타임스탬프 | 로그·이벤트 |
“2026-09-24”에 임의로 자정과 UTC를 붙이면 다른 시간대에서 23일로 보일 수 있습니다. 날만 필요한 값을 순간으로 바꿀 이유가 없다면 그대로 문자열로 보존합니다. 반대로 여러 지역에서 동시에 보아야 할 시각은 원본 시간대와 UTC 변환값을 함께 남깁니다.
서머타임은 지역 이름으로 풀어야 합니다.
“UTC+9”처럼 고정 오프셋만 저장하면 계절에 따라 오프셋이 바뀌는 지역의 예약을 정확히 재생하기 어렵습니다. Asia/Seoul처럼 IANA 지역 이름을 남기고, 입력 시점에 어떤 지역 기준인지 확인합니다. 날짜가 하루 밀렸다면 출력만 고치지 말고, 입력의 의미가 날인지 순간인지부터 다시 정합니다.
