JavaScript의 Date Parser가 통제 불능 상태이며 중단되어야 합니다

Source: Dev.to

날짜 문자열 파싱의 일관성 부족

JavaScript의 Date 생성자는 유연하도록 설계되었지만, 이 유연성 때문에 예측할 수 없는 동작이 자주 발생합니다. ISO 8601 표준에 따라 날짜 문자열을 파싱한다고 주장하지만, 입력이 유효한 ISO 문자열이 아닐 경우 브라우저별 구현으로 대체됩니다. 이러한 일관성 부족은 수십 년 동안 개발자들을 괴롭혀 왔으며, 금융 시스템부터 사용자 입력 폼에 이르기까지 다양한 애플리케이션에 버그를 초래합니다.

// example.js
const date1 = new Date('2024-03-10');
const date2 = new Date('10/03/2024');

console.log(date1); // 유효한 ISO 8601, 기대대로 파싱
console.log(date2); // 로케일 의존: Chrome → MM/DD/YYYY, Firefox → DD/MM/YYYY

한 지역에서는 정상적으로 파싱되는 날짜 문자열이 다른 지역에서는 조용히 실패하여 사용자 경험을 악화시킵니다.

ISO 8601이라 할지라도 부분 날짜 처리 방식이 브라우저마다 일관되지 않습니다:

const isoDate = new Date('2024-03-10');
console.log(isoDate.toString());
// Chrome: "Sun Mar 10 2024 00:00:00 GMT-0600 (Central Standard Time)"
// Firefox: "Sun Mar 10 2024 00:00:00 GMT-0600 (CST)"

명세에서는 YYYY‑MM‑DD를 UTC 날짜로 취급하지만, 일부 브라우저는 이를 로컬 시간으로 해석해, 결정적인 동작을 기대하는 애플리케이션을 깨뜨립니다.

타임존 및 DST 함정

Date 객체가 시스템 타임존에 의존하기 때문에 문제가 더욱 복합적으로 나타납니다. 일광 절약 시간제(DST) 전환 동안 날짜에 일수를 더하면 잘못된 결과가 나올 수 있습니다:

const date = new Date('2024-03-10T02:00:00Z');
date.setDate(date.getDate() + 7);
console.log(date.toISOString());
// DST 이동으로 인해 "2024-03-17T03:00:00Z"가 출력될 수 있음

개발자는 타임존 오프셋을 직접 고려해야 하며, 이는 오류가 발생하기 쉽고 로케일에 따라 달라집니다.

등장하는 해결책

JavaScript 생태계는 이러한 문제를 해결하기 위해 진화하고 있습니다:

• Luxon – 명시적인 타임존 지원을 갖춘 강력한 파싱·포맷 라이브러리.
• date-fns – 불변 날짜 조작을 위한 가벼운 유틸리티 라이브러리.
• Temporal API (Stage 4 제안) – Date를 대체할 표준화된 API로, 시간에 대한 정밀한 제어 제공.

예시: Luxon을 이용한 결정적 파싱

// luxon-example.js
import { DateTime } from 'luxon';

const luxonDate = DateTime.fromISO('2024-03-10', { zone: 'UTC' });
console.log(luxonDate.toJSDate()); // 언제나 2024-03-10T00:00:00Z를 나타냄

신뢰할 수 있는 날짜 처리 베스트 프랙티스

1. 입력 검증 – 엄격한 정규식이나 검증 라이브러리(예: Yup) 사용.
2. UTC로 저장·전송 – 시스템 간 타임존 드리프트 방지.
3. 최신 라이브러리 채택 – Luxon, date-fns, 혹은 곧 출시될 Temporal API 활용.

이러한 실천을 통해 우리는 혼란을 멈추고 브라우저와 지역을 초월해 일관된 동작을 하는 애플리케이션을 만들 수 있습니다.