# Date는 사라지고 Temporal이 온다 > Clean Markdown view of GeekNews topic #25784. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25784](https://news.hada.io/topic?id=25784) - GeekNews Markdown: [https://news.hada.io/topic/25784.md](https://news.hada.io/topic/25784.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-13T10:32:55+09:00 - Updated: 2026-01-13T10:32:55+09:00 - Original source: [piccalil.li](https://piccalil.li/blog/date-is-out-and-temporal-is-in/) - Points: 6 - Comments: 1 ## Summary JavaScript의 **Date 객체**는 가변성과 불일치한 파싱 규칙으로 인해 오랫동안 개발자들의 불만을 받아왔습니다. 새롭게 제안된 **Temporal API**는 불변성을 기반으로 한 명확한 날짜·시간 모델을 제공하며, `PlainDate`, `ZonedDateTime`, `Duration` 등 세분화된 클래스로 구조적 문제를 해결합니다. 모든 연산이 새로운 객체를 반환해 체이닝이 안전해지고, 시간대나 기간 계산도 일관된 방식으로 처리할 수 있습니다. 현재 Stage 3 단계에 도달한 Temporal은 Chrome과 Firefox에서 실험적으로 지원 중입니다. ## Topic Body - JavaScript의 기존 **Date 객체의 불완전성과 비일관성**을 지적하며, 이를 대체할 **Temporal API**를 소개 - Date는 **가변 객체(mutable object)** 로 동작해 실제 날짜 개념과 어긋나며, **파싱 오류·시간대 처리 한계** 등 구조적 문제가 있음 - Temporal은 **불변성 기반의 새로운 날짜·시간 처리 모델**을 제공하며, `PlainDate`, `ZonedDateTime`, `Duration` 등 세분화된 클래스 포함 - Temporal의 메서드는 기존 객체를 수정하지 않고 **새로운 객체를 반환**, 명확하고 안전한 **체이닝 연산** 가능 - Temporal은 현재 **표준화 단계 3(Stage 3)** 에 있으며, Chrome과 Firefox 등 최신 브라우저에서 실험적으로 지원 중 --- ### JavaScript의 Date 객체 문제점 - `Date` 생성자는 **불일치한 파싱 규칙**과 **비직관적 인덱싱**으로 혼란을 초래 - 예: 월(month)은 0부터 시작하지만, 일(day)과 연도(year)는 1부터 시작 - 문자열 `"99"`는 1999년으로, `"100"`은 0100년으로 해석되는 등 일관성 결여 - `Date`는 **시간(time)** 을 중심으로 설계되어 있으며, 내부적으로 **Unix 타임스탬프(밀리초 단위)** 로 저장 - **시간대(time zone)** 지원이 제한적이며, **서머타임(DST)** 이나 **비그레고리력**을 인식하지 못함 - 이러한 한계로 인해 **Moment.js**, **date-fns** 등 대형 서드파티 라이브러리 의존이 일반적이며, 이는 **성능 저하**로 이어짐 ### 불변성과 참조 개념의 충돌 - JavaScript의 **원시값(primitive)** 은 불변이며 값 자체로 저장되지만, **객체(object)** 는 참조(reference)로 저장되어 변경 가능 - `Date`는 **생성자(constructor)** 를 통해 만들어지는 객체이므로 **가변적** - 예: `setMonth()`나 `setDate()` 호출 시 원본 객체가 직접 변경됨 - 이로 인해 동일한 객체를 참조하는 변수 간에 **예상치 못한 값 변경**이 발생 - 예: `today`를 인자로 전달한 함수가 내부에서 날짜를 수정하면, 원본 `today`도 변경됨 ### Temporal: 새로운 날짜·시간 API - `Temporal`은 **생성자가 아닌 네임스페이스 객체(namespace object)** 로, `Math`와 유사한 구조 - 주요 구성: `PlainDate`, `PlainDateTime`, `PlainTime`, `ZonedDateTime`, `Duration`, `Now` 등 - `Temporal.Now`는 현재 시점의 다양한 형태를 반환 - `plainDateISO()` → ISO 형식의 날짜 - `zonedDateTimeISO()` → 시간대 포함 시각 - Temporal 객체는 **명확한 메서드 체계**를 제공 - `add({ days: 1 })`, `subtract({ years: 2 })` 등으로 **명시적 단위 연산** 수행 - 기존 객체를 수정하지 않고 **새로운 객체를 반환**, 불변성 유지 ### Temporal의 동작 방식과 장점 - Temporal 객체는 여전히 객체형이지만, **의도된 불변적 사용 패턴**을 따름 - 예: `today.add({ days: 1 })`는 새로운 날짜 객체를 반환하며, 원본 `today`는 변경되지 않음 - `Date` 대비 **간결하고 명확한 구문** 제공 - 예: ```js const today = Temporal.Now.plainDateISO(); console.log(`Tomorrow will be ${ today.add({ days: 1 }) }. Today is ${ today }.`); // 결과: Tomorrow will be 2026-01-01. Today is 2025-12-31. ``` - **시간대 지정**, **기간 계산**, **ISO 포맷 유지** 등 현대적 요구에 부합 - `add`, `subtract`, `since`, `until` 등 메서드 체이닝으로 **복잡한 날짜 계산**을 간결하게 표현 가능 ### 표준화 현황과 향후 전망 - `Temporal`은 **ECMAScript 제안 단계 3(Stage 3)** 에 도달, 브라우저 구현이 권장되는 상태 - **Chrome**과 **Firefox**에서 이미 실험적 지원이 시작되었으며, 다른 브라우저도 도입 예정 - 개발자들은 현재부터 **테스트 및 피드백 제공**을 통해 사양 개선에 참여 가능 - `Date`는 여전히 존재하겠지만, 향후에는 **Temporal이 기본 날짜 처리 방식**으로 자리잡을 전망 - 글은 “1995년에 교체했어야 했지만, 지금이라도 Temporal.Now가 최적의 시점”이라며 마무리 --- ## Comments ### Comment 49131 - Author: neo - Created: 2026-01-13T10:32:56+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46589658) - 이 글은 JavaScript의 **Date 생성자**가 가진 여러 황당한 동작을 다루고 있음 특히 `'YYYY-MM-DD'` 형식이 **UTC 자정**으로 해석되어, 로컬 시간대에서는 하루가 어긋나는 문제를 설명함 원래 ISO 8601에서는 시간대 지정이 없으면 로컬 시간으로 간주해야 하지만, ES5 스펙 작성 중 실수로 “Z”(UTC)로 처리되었음 이후 ES2015에서 수정하려 했으나, 수많은 웹사이트가 기존의 잘못된 동작에 의존하고 있어 **웹 호환성**을 이유로 되돌려졌음 자세한 내용은 [Broken Parser 섹션](https://maggiepint.com/2017/04/11/fixing-javascript-date-web-compatibility-and-reality/) 참고 - `'use strict'`처럼 `'strict datetime'` 지시어가 있었다면 좋았을 것 같음 이렇게 하면 기존 코드와의 **비호환성 문제** 없이 올바른 동작을 선택적으로 적용할 수 있었을 것임 혹은 `import Date from 'browser:date'`처럼 내부 모듈로 **수정된 전역 객체**를 불러오는 방식도 가능했을 것임 - 나도 예전에 문자열을 직접 분리해 **시간대 없는 날짜 객체**를 만들었음 생일처럼 단순히 날짜만 의미하는 값이 시간대 때문에 바뀌는 건 말이 안 됨 예전에 Outlook이 생일을 시간대 포함으로 저장해서, 나라를 옮길 때마다 생일이 하루씩 밀렸던 기억이 있음 - “웹 호환성의 제단에 바쳐졌다”는 표현이 인상적임 하지만 대안이 있었을까? 예전 IE5 시절처럼 브라우저 버전별 분기 처리를 강제하는 건 더 나빴을 것 같음 - [jsdate.wtf](https://jsdate.wtf/) 사이트를 보면 JS Date의 **기괴한 동작들**을 직접 체험할 수 있음 - 이런 문제들이 수많은 **작은 버그의 근원**이 되는 걸 생각하면 웃기면서도 슬픈 일임 - Rails와 Ruby의 **시간 처리 방식**을 정말 부러워함 `Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour` 같은 API는 직관적이고 강력함 Ruby는 Time 객체를 **하나의 일관된 객체**로 오버로드해서, 변환이나 캐스팅 고민이 거의 없음 JS에서도 `new Date().add({ days: 1 })`처럼 간단히 쓸 수 있다면 얼마나 좋을까 생각함 - 하지만 “3.days - 4.months + 1.hour” 같은 문법이 좋은가에 대해서는 의문을 제기함 또한 코어 라이브러리를 오버로드하는 게 정말 좋은 접근인지도 논쟁의 여지가 있음 - Safari가 아직 **Temporal API**를 지원하지 않는 게 아쉬움 내년쯤에는 지원되길 기대함 - JavaScript의 Date가 가진 문제는 많지만, **객체라는 점 자체**는 큰 문제가 아니라고 생각함 불변 객체였으면 좋았겠지만, 변경 가능한 객체가 변경된다고 놀랄 일은 아님 - 하지만 다른 코드가 내가 들고 있던 Date 객체를 **암묵적으로 변경**할 수 있다는 점이 문제임 가변성의 진짜 위험은 로컬이 아닌 **비지역적 변경**에서 발생함 - Temporal API가 **윤초(leap second)** 정보를 전혀 다루지 않는 게 불편함 천문 계산용 JS 도구를 만들고 싶은데, UTC 변환에는 윤초 데이터가 필요함 `temporal-tai` 같은 우회책은 있지만, **클라이언트 측에서 윤초 파일을 유지**해야 해서 번거로움 SOP(CORS 정책) 때문에 외부 사이트에서 파일을 바로 가져올 수도 없음 브라우저는 주기적으로 업데이트되는데, 왜 윤초 정보를 내장하지 않는지 의문임 - SOP가 윤초 파일을 막는다는 건 오해임 서버에서 `Access-Control-Allow-Origin` 헤더를 설정하거나 JS 파일 형태로 제공하면 가능함 다만 브라우저가 자체적으로 윤초 데이터를 포함하고 유지하는 건 **비용이 큰 작업**일 수 있음 - “UTC만 다룬다”는 표현은 부정확함 UTC는 본래 윤초를 포함하는 시간 척도이므로, 실제로는 **POSIX 시간**만 다루고 있다고 보는 게 맞음 - 코드 예시에서 `"33"`이 아니라 `"50"`부터 1900년대로 처리된다고 해야 함 — 단순한 **오타 지적**임 - [Temporal polyfill](https://github.com/js-temporal/temporal-polyfill)을 사용 중인데, 지금까지 아주 만족스러움 - 다만 크기가 **51KB**라서 가벼운 편은 아님 ([bundlephobia 링크](https://bundlephobia.com/package/@js-temporal/polyfill@0.5.1)) 서버나 대형 앱에는 괜찮지만, 작은 앱에는 부담이 될 수 있음 - moment나 luxon과 비교했을 때 어떤지 궁금하다는 질문도 나옴 - 글이 이상하게도 `Date.now()`를 전혀 언급하지 않음 Temporal과 비교하려면 `Date.now()`를 기준으로 설명했어야 함 이 함수는 1970년 1월 1일부터의 **밀리초 단위 경과 시간**을 반환함 Temporal이 더 친절한 API이긴 하지만, 근본적으로는 시간의 **상대적 거리**를 표현하는 것이 목적임 - 하지만 글에서 언급된 **타임스탬프 관련 버그**도 존재함 그렇다면 Date를 거치지 않고 원하는 형식으로 변환하는 방법은 무엇인지 궁금함 - “daylight savings time”이 아니라 “daylight **saving** time”이 맞다는 **사소하지만 중요한 교정**을 남김 - 지금까지 JS Date가 이렇게 엉망인 줄 몰랐음 - 더 안타까운 건, 이런 문제들이 **1995년부터 이미 명확히 보였다는 점**임 그때 조금만 더 신중했다면 수많은 개발자가 이런 함정에 빠지지 않았을 것임