아침 8시인데 날짜는 어제? JavaScript toISOString의 UTC 기준

toISOString()은 같은 시점을 UTC로 표현합니다. 그 앞 10글자를 잘라도 한국 날짜로 바뀌지는 않습니다. 현대 한국 시간(UTC+09:00)의 자정부터 오전 9시 직전까지는 UTC의 달력 날짜가 전날입니다.

AI와 함께 날짜 표시 코드를 만들다가 ‘오늘’이 어제로 나온다면, 먼저 이 한 줄이 원하는 시간대를 쓰는지 보세요. 예를 들어 한국의 2026년 10월 17일 오전 8시는 다음과 같이 표현됩니다.

const instant = new Date("2026-10-17T08:00:00+09:00");
console.log(instant.toISOString());
// "2026-10-16T23:00:00.000Z"
console.log(instant.toISOString().slice(0, 10));
// "2026-10-16"

시점이 과거로 옮겨 간 것이 아닙니다. 한국에서는 17일 오전 8시인 같은 순간이 UTC에서는 16일 23시인 것입니다.

한국 시각 2026년 10월 17일 오전 8시는 UTC로 10월 16일 23시입니다. 이 조건에서 날짜가 다르게 보이는 이유를 설명하는 개념도이며, 시간이 이동하거나 toISOString이 잘못 작동한 것은 아닙니다.

toISOString은 한국 날짜 표시 함수가 아닙니다

ECMAScript의 toISOString 정의는 UTC 시간척도로 문자열을 반환하고 UTC 오프셋을 Z로 표시한다고 정합니다. 따라서 한국에서 실행했다는 이유만으로 반환 문자열이 한국 시간이 되지는 않습니다.

slice(0, 10)은 문자열을 자르는 동작입니다. 통상적인 4자리 연도의 ISO 문자열에서 날짜 부분을 떼어 낼 수 있지만, 시간대를 변환하지는 않습니다. toISOString이 잘못 계산했다기보다 ‘UTC 날짜’와 ‘한국 업무 날짜’ 중 무엇이 필요한지를 코드에 담지 않은 경우입니다.

한국 시각 2026년 10월 17일 08:00과 UTC 2026년 10월 16일 23:00은 같은 시점입니다. 두 시점 사이를 이동하는 그림이 아니라, 한 시점을 서로 다른 시간대의 날짜로 표현한 그림입니다.

한국 달력 날짜가 필요하면 시간대를 명시합니다

아래 예제는 시점 자체에 9시간을 더하는 대신, 같은 시점을 Asia/Seoul 기준으로 표시합니다. Intl.DateTimeFormat의 year·month·day 부분을 골라 원하는 순서로 조립합니다.

function seoulDate(instant) {
  const parts = new Intl.DateTimeFormat("en-US", {
    timeZone: "Asia/Seoul",
    year: "numeric",
    month: "2-digit",
    day: "2-digit"
  }).formatToParts(instant);
  const p = Object.fromEntries(
    parts.map(x => [x.type, x.value])
  );
  return p.year + "-" + p.month + "-" + p.day;
}
console.log(seoulDate(
  new Date("2026-10-17T08:00:00+09:00")
));
// "2026-10-17"

ECMA-402의 DateTimeFormat 생성 절차에서 timeZone을 생략하면 시스템의 시간대를 사용합니다. 언어·표시 관습을 고르는 locale과 시간대를 고르는 timeZone은 다른 옵션입니다. locale만 한국어로 바꿨다고 한국 시간대가 지정되는 것은 아닙니다.

formatToParts의 type·value 부분 배열을 사용한 이유도 구분해 두세요. 함수가 YYYY-MM-DD를 그대로 보장하는 것이 아니라, 예제의 코드가 year·month·day를 골라 그 순서로 붙입니다. 여기서는 시험한 en-US 옵션과 Node 환경으로 범위를 한정합니다. 다른 달력·숫자체계·모든 브라우저의 결과까지 확인한 코드는 아닙니다.

09시 정각과 연도 경계도 따로 확인했습니다

2026년 10월 17일, Windows x64의 Node.js 26.5.0(V8 14.6.202.34-node.24, ICU 78.3)에서 고정된 합성 시점 네 개를 비교했습니다. 각 입력에 +09:00을 명시했고, 프로세스 시간대를 Asia/Seoul과 UTC로 각각 바꿔 같은 결과가 나오는지 확인했습니다.

입력의 한국 시각	UTC 앞 10글자	예제의 한국 날짜
2026-10-17 00:00:00	2026-10-16	2026-10-17
2026-10-17 08:59:59	2026-10-16	2026-10-17
2026-10-17 09:00:00	2026-10-17	2026-10-17
2027-01-01 00:00:00	2026-12-31	2027-01-01

09시 정각에는 UTC도 같은 날짜가 됩니다. ‘오전 9시까지 전날’이라고 뭉뚱그리면 경계를 잘못 설명하게 됩니다. 유효하지 않은 Date에서 toISOString을 호출하면 RangeError가 나는 경우도 별도로 확인했습니다. 날짜 입력을 읽는 문제와 시간대를 표시하는 문제는 나눠 봐야 합니다.

시험은 오프셋을 명시한 Node 예제로 한정했습니다. 실제 웹앱·데이터베이스·AI의 앱 수정 동작, 시간대 없는 문자열의 해석이나 날짜만 저장하는 업무 규칙까지 확인한 결과는 아닙니다.

한국 달력 날짜를 보여 주는 일과 UTC 기준 시점을 보관하는 일은 목적이 다릅니다. 달력과 기록 띠는 그 차이를 설명하는 비유이며, 실제 서비스 화면이나 로그 증거가 아닙니다.

UTC로 남겨야 하는 시점까지 바꾸지는 마세요

기록 시각이나 시스템 간 교환값을 UTC로 보관하려는 목적이라면 toISOString의 UTC 표현이 맞습니다. 한국 달력의 ‘오늘’을 표시하는 것과 사건이 일어난 시점을 보관하는 것은 다른 일입니다. 코드에서 toISOString을 찾았다고 전부 교체할 이유는 없습니다.

AI에게 수정 요청을 할 때도 ‘시간 오류를 전부 고쳐’보다 ‘이 화면의 오늘 날짜는 Asia/Seoul 기준으로 표시하고, UTC 시점 보관은 유지해’처럼 두 목적을 나눠 적을 수 있습니다. 이 문장은 요청 범위를 정하는 예시이지, 어떤 AI 도구의 수정 성공을 시험한 결과는 아닙니다.

수정 뒤 어떤 증거를 남길지 고민된다면 AI가 고친 코드를 검수하는 순서를 함께 볼 수 있습니다. 날짜 문제에서는 우선 같은 고정 시점을 넣고, UTC 표현과 원하는 달력 날짜를 따로 비교하는 것이 핵심입니다.

출처 및 확인일

• Ecma International / TC39, ECMAScript® 2027 Language Specification — Date.prototype.toISOString. 관찰 시점의 living draft, 조항별 게시·수정일 미표기. 확인: 2026-10-17 KST.
• Ecma International, ECMA-402, 13th edition — ECMAScript® 2026 internationalization API specification. 2026-06. CreateDateTimeFormat·FormatDateTimeToParts 등 해당 조항 확인. 확인: 2026-10-17 KST.