시각 끝의 Z는 무엇을 약속하나요?
2026-01-01T00:30:00Z는 UTC 기준 2026년 1월 1일 0시 30분을 뜻합니다. 끝의 Z는 UTC라는 기준을 명시합니다. 같은 숫자에 시간대 설명이 없으면 어느 지역의 시계를 읽은 것인지 알기 어렵습니다.
이 활동은 Z 또는 UTC 오프셋을 포함한 세 개의 완전한 시각만 제공합니다. 사용 중인 컴퓨터의 기본 시간대를 추측하지 않고, 표시할 도시도 명시적으로 고릅니다.
같은 순간을 두 도시에서 어떻게 읽나요?
이 순간의 서울 시각은 2026년 1월 1일 09:30입니다. 로스앤젤레스에서는 2025년 12월 31일 16:30입니다. 날짜뿐 아니라 연도도 다르지만 두 표시는 같은 순간을 가리킵니다.
자바스크립트의 Date는 그 순간을 나타내는 시간 값을 보관합니다. Intl.DateTimeFormat의 timeZone을 바꾸면 그 값을 다른 지역 달력과 시계로 표현합니다. 이 표시 작업이 원래 순간을 앞으로나 뒤로 이동시키지는 않습니다.
무엇이 변하지 않았는지 어떻게 확인하나요?
활동에는 원본 UTC 시각과 getTime() 값을 함께 표시합니다. UTC·서울·로스앤젤레스를 눌러 날짜가 바뀌는 동안 getTime()이 같은지 확인하세요. 이 값은 1970년 1월 1일 00:00 UTC부터 센 밀리초 수입니다.
이번에는 다른 ‘원본 순간’을 고르면 getTime()도 달라집니다. 시간대만 바꾼 경우와 원본 순간을 바꾼 경우를 비교하면 두 조작이 서로 다른 일을 한다는 점이 드러납니다.
왜 ISO 문자열의 앞 열 글자만 잘라서는 부족한가요?
toISOString()은 UTC 기준으로 표현합니다. 그 앞의 YYYY-MM-DD를 잘라 얻은 날짜는 UTC 날짜이지 언제나 사용자의 지역 날짜는 아닙니다. 예를 들어 2026-10-24T15:30:00Z는 서울에서 이미 10월 25일 00:30입니다.
한국 날짜별로 글을 묶거나 행사를 표시하려면 먼저 Asia/Seoul로 형식화한 달력 날짜를 사용해야 합니다. 이미 특정 날짜 자체를 뜻하는 자료와 시점을 지역 날짜로 바꾸는 일도 구별합니다. 생일처럼 시각 없는 달력 날짜를 무조건 UTC 순간으로 바꾸는 것은 별도 설계 문제입니다.
도시의 시차를 늘 같은 숫자로 두어도 되나요?
로스앤젤레스는 여름시간제를 적용하므로 날짜에 따라 UTC와의 차이가 달라집니다. 신년 사례에서는 UTC보다 8시간 늦고, 활동의 7월 사례에서는 7시간 늦게 표시됩니다. 서울은 이 사례들에서 UTC보다 9시간 빠릅니다.
따라서 도시를 다룰 때는 고정 숫자만 더하는 대신 IANA 시간대 이름과 해당 날짜의 규칙을 사용합니다. 이 활동의 출력은 브라우저 시간대 자료에 따른 형식화이며, 미래의 법이나 지역 규칙이 영구히 유지된다는 보장은 아닙니다.