Temporal이 JavaScript의 날짜·시간 문제를 해결하기까지 9년에 걸친 표준화, 구현, 생태계 통합 과정을 다룹니다.
2026년 3월 11일 게시
블로그에 오신 것을 환영합니다! 저는 Bloomberg의 JavaScript Infrastructure 및 Terminal Experience 팀의 시니어 소프트웨어 엔지니어 Jason Williams입니다. 오늘날 Bloomberg Terminal은 매우 많은 JavaScript를 실행합니다. 우리 팀은 회사 전반의 엔지니어들에게 JavaScript 환경을 제공합니다.
Bloomberg는 JavaScript를 이야기할 때 가장 먼저 떠올리는 회사는 아닐 수 있습니다. 적어도 제가 여기서 일하기 전인 2018년에는 확실히 그렇지 않았습니다. 당시 저는 런던에서 열린 첫 TC39 회의에 참석했는데, 그 자리에서 Realms, WebAssembly, Class Fields, 그리고 다른 주제들을 논의하러 온 Bloomberg 엔지니어들을 만났습니다. 이 회사는 이제 Igalia와의 파트너십을 포함해 수년간 JavaScript 표준화에 참여해 왔습니다. 우리가 지원한 제안들로는 Arrow Functions, Async Await, BigInt, Class Fields, Promise.allSettled, Promise.withResolvers, WeakRefs, Source Maps 표준화, 그리고 그 밖에도 더 많은 것들이 있습니다!
제가 처음 참여한 제안은 Promise.allSettled였고, 매우 보람찼습니다. 그 일이 마무리된 뒤, 저는 Temporal이라는 날짜와 시간 관련 제안에도 힘을 보태기로 했습니다.
JavaScript는 모든 브라우저에서 실행된다는 점에서 독특합니다. 단일한 “소유자”가 없기 때문에, 어딘가에서 고립된 채로 변경을 만들어 놓고 그것이 어디서나 적용될 것이라고 기대할 수 없습니다. 모든 당사자의 동의가 필요합니다. 진화는 ECMAScript를 책임지는 기술 위원회인 TC39를 통해 이루어집니다.
제안은 일련의 성숙도 단계를 거칩니다:
2018년에 제가 처음 Temporal을 살펴봤을 때는 Stage 1이었습니다. TC39 위원회는 문제가 실재한다는 데 동의한 상태였습니다. JavaScript에 날짜·시간을 위한 완전히 새로운 라이브러리를 들여오자는 급진적인 제안이었죠. 이 제안은:
하지만 우리는 어떻게 여기까지 오게 되었을까요? 왜 Date가 그렇게 큰 고충 지점이었을까요? 이를 위해서는 잠시 뒤로 돌아가야 합니다.
1995년, Brendan Eich는 10일 스프린트로 Mocha(훗날 JavaScript가 됨)를 만들라는 과제를 받았습니다. 극심한 시간 압박 속에서 많은 설계 결정은 실용적일 수밖에 없었습니다. 그중 하나가 Java의 Date 구현을 그대로 이식(port)하는 것이었습니다. Brendan은 나중에 이렇게 설명했습니다:
Ken Smith(“Mocha”에서 내가 직접 쓰지 않은 유일한 코드)가 Java의 Date 코드를 Java에서 C로 그대로 포팅한 것이었다.
당시에는 합리적이었습니다. Java는 상승세였고, JavaScript는 그 가벼운 동반자 언어로 자리매김하고 있었습니다. 내부적으로는 이 철학을 MILLJ: Make It Look Like Java라고 부르기도 했습니다.
Brendan은 API를 바꾸는 일이 정치적으로 어려웠을 것이라고 덧붙이기도 했습니다:
모두가 Java를 “형님” 언어로 기대하던 때에 그것을 바꾸면 혼란과 버그가 생길 것이고, Sun도 반대했을 것이다.
그 순간에는 시간 모델을 근본적으로 재고하는 것보다 Java와의 일관성이 더 중요했습니다. 이는 실용적 절충이었습니다. 웹은 아직 어렸고, 적어도 처음에는 JavaScript를 활용하는 대부분의 애플리케이션도 단순했을 것입니다.
2010년대에 이르러 JavaScript는 은행 시스템, 트레이딩 터미널, 협업 도구, 그리고 지구상의 모든 시간대에서 돌아가는 다른 복잡한 시스템들을 구동하고 있었습니다. Date는 개발자들에게 점점 더 큰 고충 지점이 되어 갔습니다.
개발자들은 종종 원본 Date 객체를 그대로 변경(mutate)해 버리는 헬퍼 함수를 실수로 작성하곤 했습니다. 새 객체를 반환하려 했던 의도와 달리 말이죠:
const date = new Date("2026-02-25T00:00:00Z");
console.log(date.toISOString());
// "2026-02-25T00:00:00.000Z"
function addOneDay(d) {
// oops! This is mutating the date
d.setDate(d.getDate() + 1);
return d;
}
addOneDay(date);
console.log(date.toISOString());
// "2026-02-26T00:00:00.000Z"const billingDate = new Date("Sat Jan 31 2026");
billingDate.setMonth(billingDate.getMonth() + 1);
// Expected: Feb 28
// Actual: Mar 02사람들은 때때로 “그 달의 마지막 날”을 얻고 싶어 하다가 이런 함정에 빠집니다. 월을 1 증가시키되 일(day)은 그대로 유지되기 때문입니다. Date는 유효하지 않은 달력 결과를 유효한 날짜로 되돌려 제약하지 않습니다. 대신 오버플로를 다음 달로 조용히 넘겨 버립니다.
new Date("2026-06-25 15:15:00").toISOString();
// Potential Return Values:
// - local TimeZone
// - Invalid Date RangeError
// - UTC이 예에서 문자열은 ISO 8601과 비슷하지만 동일하지는 않습니다. 역사적으로 “거의 ISO” 문자열에 대한 브라우저 동작은 명세에서 정의되지 않았습니다. 어떤 브라우저는 로컬 시간으로, 어떤 브라우저는 UTC로, 또 어떤 브라우저는 아예 유효하지 않은 입력으로 예외를 던졌습니다.
이 외에도 훨씬 더 많은 문제가 있지만, 요점은 Date가 지난 30년 동안 JavaScript 개발자들에게 고통의 원천이었다는 것입니다.
웹 생태계는 라이브러리로 Date의 결함을 메울 수밖에 없었습니다. 아래에서 datetime 라이브러리의 폭발적인 증가를 볼 수 있습니다. 오늘날 이들은 주당 1억 건이 넘는 다운로드로 합산됩니다.
선두에는 Moment.js가 있었습니다. 표현력 있는 API, 강력한 파싱 기능, 그리고 절실했던 불변성을 자랑합니다. 2011년에 만들어진 Moment.js는 빠르게 JavaScript에서 날짜·시간 조작을 다루는 사실상의 표준이 되었습니다. 그렇다면 문제가 해결된 걸까요? 다들 이걸 가져다 쓰면 끝일까요?
moment.js(그리고 다른 유사 라이브러리)의 광범위한 채택은 그 자체로 또 다른 문제를 낳았습니다. 라이브러리를 추가한다는 것은 번들 크기를 키운다는 뜻이었는데, 로케일 정보 세트와 시간대 데이터베이스의 시간대 데이터까지 함께 배송해야 했기 때문입니다.
미니파이어, 컴파일러, 정적 분석 도구를 사용하더라도, 대부분의 개발자는 어떤 로케일이나 시간대가 필요할지 미리 알지 못합니다. 안전하게 가려면 데이터를 트리 셰이킹으로 제거할 수 없었습니다. 결국 대다수 사용자는 모든 데이터를 통째로 가져가 사용자에게 함께 전송했습니다.
Moment.js의 메인터이너였던 Maggie Johnson-Pint(다른 사람들과 함께)는 패키지 크기에 대한 요청이 끊이지 않는 상황에 익숙했습니다.
moment는 모듈, webpack, React 때문에 모두가 불변을 원한다는 것 등을 따라가는 유지보수 비용이 새로운 기능 추가보다 더 커진 지점까지 와 있었다
그리고 물론 사람들은 크기 이야기를 절대 멈추지 않는다.
2017년 Maggie는 그해 TC39 총회를 위해 “Temporal Proposal”로 날짜·시간을 표준화할 때가 왔다고 판단했습니다. 큰 호응을 얻어 Stage 1로 진전했습니다.
Stage 1은 큰 이정표였지만, 여전히 결승선과는 거리가 멀었습니다. 초기의 에너지 폭발 이후, 진전은 자연스럽게 느려졌습니다. Maggie와 Matt Johnson-Pint가 Brian Terlson과 함께, Microsoft 내부의 다른 책임을 병행하며 노력을 이끌고 있었습니다. Temporal은 아직 초기였기 때문에 당장 해야 할 일의 상당수는 화려하지 않았습니다. 요구사항 수집, 의미론의 정리, 그리고 “생태계의 고통”을 실제로 출시 가능한 설계로 번역하는 일이었죠.
Bloomberg에서 그 고통은 이론이 아니었습니다.
우리는 Terminal 전반에 걸쳐 대규모로 JavaScript를 실행하며, Chromium, Node.js, SpiderMonkey 같은 기반 런타임과 엔진을 사용합니다. 사용자와 그들이 투자하는 금융 시장은 지구상의 모든 시간대에 걸쳐 있습니다. 우리는 타임스탬프를 끊임없이 주고받습니다. 서비스 간, 저장소로, UI로, 그리고 “지금(now)”이 무엇인지에 대해 모두가 합의해야 하는 시스템 간에 말이죠. 심지어 정부가 DST 규칙을 거의 예고 없이 바꾸는 경우에도 말입니다.
게다가 우리는 기본 Date 모델이 애초에 설계되지 않았던 요구사항도 갖고 있었습니다:
Maggie가 TC39에 Temporal을 가져오던 것과 병행해, Bloomberg 엔지니어 Andrew Paprocki는 Igalia와 V8에서 시간대를 구성 가능하게 만드는 방안을 논의하고 있었습니다. 구체적으로는 OS 기본값에 의존하는 대신 embedder가 “인지되는(perceived)” 시간대를 제어할 수 있도록, 지원되는 간접 계층(indirection layer)을 도입하는 내용이었습니다. 그 대화에서(당시 Igalia에서 일하던) Daniel Ehrenberg는 Andrew에게 초기 Temporal 작업을 가리켰는데, Bloomberg의 기존 값 의미(value-semantic) datetime 타입들과 놀랄 만큼 닮아 보였기 때문입니다.
그 교류는 Bloomberg의 프로덕션 요구, Igalia의 브라우저·표준 전문성, 그리고 Temporal의 부상하는 방향을 잇는 초기 다리가 되었습니다. 그 후 수년 동안 Bloomberg는 Igalia와 협력했고(지속적인 자금 지원 포함) Temporal을 진전시키는 데 직접 엔지니어링 시간을 투입했습니다. 그 결과 Temporal은 결국 생태계 전체가 배송할 수 있는 무언가가 되었습니다. Andrew는 Bloomberg 내부에서 Temporal을 더 밀어붙이는 데 도움을 줄 자원자를 찾고 있었고, Philipp Dunkel이 명세 챔피언(spec champion)으로 자원했습니다. 그는 Andrew와 함께 Temporal을 현실로 만들기 위해 Bloomberg가 투자하도록 설득했고, Igalia와의 더 깊은 파트너십도 포함되었습니다. 그 지원으로 Philip Chimento와 Ujjwal Sharma가 전임 Temporal 챔피언으로 합류해, 제안이 계속 전진하는 데 필요한 일상적인 집중력을 더했습니다.
Shane Carr는 Google의 Internationalization 팀을 대표해 챔피언 팀에 합류했습니다. 그는 달력 같은 국제화 주제에 필요한 집중을 제공했고, 또한 표준화 과정과 Intl(포맷팅, 시간대, 달력 등) 관련 도구에서 고통을 겪는 사용자들의 목소리를 이어주는 접착제 역할도 했습니다.
마지막으로, Justin Grant가 2020년에 자원자로 Temporal 챔피언에 합류했습니다. 그는 타임스탬프 데이터를 다루는 세 개의 서로 다른 스타트업에서 10년을 보낸 뒤였고, 엔지니어링 팀이 날짜, 시간, 시간대 실수를 고치느라 수천 시간을 낭비하는 모습을 봐 왔습니다. Justin의 경험은 우리를 실제 사용 사례에 단단히 붙잡아 두었고, 개발자들이 저지를 실수를 예측하게 했으며, DST 버그를 과거의 것으로 만들기 위해 Temporal.ZonedDateTime API가 반드시 포함되도록 하는 데 기여했습니다.
이 목록에 없지만 언급할 만한 인물로는 Daniel Ehrenberg, Adam Shaw, Kevin Ness 등이 있습니다.
Temporal은 전역 스코프에 존재하는 최상위 네임스페이스 객체로(Math나 Intl과 유사) 제공됩니다. 그 아래에는 생성자 형태의 “타입”들이 있습니다. 개발자들은 API를 사용할 때 필요한 타입(예: Temporal.PlainDateTime)을 골라 사용하게 될 것으로 기대됩니다.
Temporal에 포함된 타입은 다음과 같습니다:
어떤 Temporal 타입이 필요한지 모르겠다면 Temporal.ZonedDateTime부터 시작하세요. 개념적으로 Date에 가장 가까운 대체재이지만, “발밑 지뢰(footguns)”는 없습니다.
Date가 나타내는 것:
Temporal.ZonedDateTime가 나타내는 것:
현재 다음과 같이 작성하고 있다면:
const now = new Date();Temporal에서의 대응은 다음과 같습니다:
const now = Temporal.Now.zonedDateTimeISO();위 예는 Now 네임스페이스를 사용하며, 현재 로컬 시간과 시간대가 이미 설정된 타입을 제공합니다.
이 타입은 일광절약시간 전환이 문제를 일으킬 수 있는 datetime 산술을 필요로 할 수 있는 DateTime에 최적화되어 있습니다. ZonedDateTime은 시간의 덧셈과 뺄셈을 수행할 때 이러한 전환을 고려할 수 있습니다(아래 예 참고).
// London DST starts: 2026-03-29 01:00 -> 02:00
const zdt = Temporal.ZonedDateTime.from(
"2026-03-29T00:30:00+00:00[Europe/London]",
);
console.log(zdt.toString());
// → "2026-03-29T00:30:00+00:00[Europe/London]"
const plus1h = zdt.add({ hours: 1 });
console.log(plus1h.toString());
// "2026-03-29T02:30:00+01:00[Europe/London]" (01:30 doesn't exist)이 예에서는 01:30이 아니라 02:30에 도착합니다. 그 시점의 01:30은 존재하지 않기 때문입니다.
Temporal.Instant는 정확한 시간의 한 순간이며, 시간대도 없고, 일광절약시간도 없고, 달력도 없습니다. 1970년 1월 1일 자정부터 경과한 시간을 나타냅니다(Unix epoch). 매우 유사한 데이터 모델을 가진 Date와 달리 Instant는 밀리초가 아니라 나노초 단위로 측정됩니다. 챔피언들은, 브라우저가 보안 목적으로 일부 정밀도를 낮추는(coarsening) 경우가 있더라도, 개발자들이 외부에서 생성된 나노초 기반 타임스탬프를 다뤄야 한다는 이유로 이 결정을 내렸습니다.
Temporal.Instant의 전형적인 사용 예는 다음과 같습니다:
// One exact moment in time
const instant = Temporal.Instant.from("2026-02-25T15:15:00Z");
instant.toString();
// "2026-02-25T15:15:00Z"
instant.toZonedDateTimeISO("Europe/London").toString();
// "2026-02-25T15:15:00+00:00[Europe/London]"
instant.toZonedDateTimeISO("America/New_York").toString();
// "2026-02-25T10:15:00-05:00[America/New_York]"Instant를 생성한 뒤 서로 다른 “zoned” DateTime으로 변환할 수 있습니다(이에 대해서는 뒤에서 더 설명합니다). 보통은 Instant를(원하는 백엔드 저장소에) 저장하고, 이후 사용자의 시간대에 맞춰 동일한 시간을 표시하기 위해 시간대 변환을 사용하게 될 것입니다.
또한 plain 타입들의 계열도 있습니다. 이는 “벽시계 시간(wall time)”이라고 부를 수 있는데, 벽에 걸린 아날로그 시계를 떠올리면 일광절약시간이나 시간대를 확인하지 않습니다. 그저 순수한 시간입니다(일광절약시간 전환 중이라도 시계를 한 시간 앞으로 돌리면 벽시계도 한 시간 앞으로 갑니다).
점점 더 적은 정보를 담는 여러 타입이 있습니다. 이는 유용합니다. 표현하고 싶은 값에 맞는 타입을 선택할 수 있고, 필요하지 않은 데이터에 대한 계산을 걱정할 필요가 없기 때문입니다(예를 들어 날짜만 표시하려면 시간을 계산할 필요가 없습니다).
이 타입들은 사용자에게 값만 표시할 계획이고, 주 단위로 앞뒤로 이동(달력이 필요)하거나 시간 단위로 이동(일광절약시간 경계를 넘을 수 있음) 같은 날짜/시간 산술을 수행할 필요가 없을 때도 유용합니다. 또한 일부 타입의 제약이 바로 그 유용함의 이유이기도 합니다. 실수로 예상치 못한 버그에 부딪히기가 어렵습니다.
const date = Temporal.PlainDate.from({ year: 2026, month: 3, day: 11 }); // => 2026-03-11
date.year; // => 2026
date.inLeapYear; // => false
date.toString(); // => '2026-03-11'Temporal은 달력을 지원합니다. 브라우저와 런타임은 내장 달력 세트를 함께 제공하며, 이는 그레고리력을 단지 다른 방식으로 포맷하는 것이 아니라, 사용자가 선호하는 달력 체계로 표현하고 표시하고 산술을 수행할 수 있게 합니다.
Temporal 객체는 달력을 인지하기 때문에, “한 달 더하기” 같은 연산은 그 달력의 규칙에 따라 수행되어 기대한 결과에 도달합니다. 아래 예에서는 히브리 달력 날짜에 히브리 달력 기준으로 한 달을 더합니다:
const today = Temporal.PlainDate.from("2026-03-11[u-ca=hebrew]");
today.toLocaleString("en", { calendar: "hebrew" });
// '22 Adar 5786'
const nextMonth = today.add({ months: 1 });
nextMonth.toLocaleString("en", { calendar: "hebrew" });
// '22 Nisan 5786'레거시 Date로는 “히브리 달력 기준으로 한 달 더하기”를 1급 연산으로 표현할 방법이 없습니다. 다른 달력으로 _포맷_할 수는 있지만, 산술은 내부적으로 여전히 그레고리력 월 산술입니다.
이를 Date로 근사하려 하면 다음과 비슷해질 수 있습니다:
const legacyDate = new Date(2026, 2, 11);
legacyDate.toLocaleDateString("en", { calendar: "hebrew" });
// '22 Adar 5786'
legacyDate.setMonth(legacyDate.getMonth() + 1);
legacyDate.toLocaleDateString("en", { calendar: "hebrew" });
// '24 Nisan 5786'이는 그레고리력 기준으로 한 달(3월 → 4월)을 더합니다. 그런 다음 결과를 히브리 달력으로 _표시_하면, 달력의 월 구조나 월 길이가 같지 않기 때문에 22 Nisan이 아니라 24 Nisan이라는 다른 날짜에 도달합니다.
마지막 타입은 Temporal.Duration입니다. Duration은 직관적이며, 다른 타입들과 함께 덧셈과 뺄셈에 사용할 수 있습니다. Duration의 또 다른 유용한 기능은 아래 예처럼 서로 다른 단위로 총량을 나타내는 것입니다:
const duration = Temporal.Duration.from({
hours: 130,
minutes: 20,
});
duration.total({ unit: "second" }); // => 469200대부분의 datetime 라이브러리는 이미 duration 타입을 갖고 있으므로, 포함하는 것이 합리적이었습니다. 또한 개발자가 Time 또는 DateTime을 비교해서 Duration 타입을 돌려받을 수 있게 함으로써 다른 타입들을 보완합니다.
Temporal 구현은 도전이었습니다. 프로그래밍 언어 역사상 그 어떤 제안보다도 JavaScript에 더 많은 변화를 가져오는 매우 큰 제안이기 때문입니다. 구체적인 어려움으로는 다음이 있습니다:
Temporal은 ES2015 이후 ECMAScript에 추가된 가장 큰 기능이다
Firefox는 André Bargull(온라인에서는 Anba로 알려짐)의 뛰어난 작업 덕분에 명세화되는 동안 Temporal을 구현할 수 있었지만, 모든 브라우저나 엔진이 초기 단계에서 Temporal 작업을 할 수 있었던 것은 아닙니다. 이는 Stage 3 후반부에 많은 따라잡기 작업이 필요했다는 뜻입니다.
공식 ECMAScript 테스트 스위트(Test262)에 추가된 테스트 수로 보면, Temporal은 ECMAScript 명세에 추가된 것 중 가장 큽니다. 오늘날 Temporal은 약 4,500개의 테스트를 갖고 있으며, 전임자인 Date를 포함해 다른 내장 객체들에 비해 매우 큰 수치입니다.
2024년 6월 총회에서 Google Internationalization 팀과 Boa는 Temporal 구현을 위해 협력하기로 했고, 두 엔진에서 공통으로 사용할 수 있는 Rust 라이브러리를 만들기로 결정했습니다. 이 라이브러리는 temporal_rs라고 합니다. 2024년과 2025년에 걸쳐 Kevin Ness, Manish Goregaokar, Jose Espina와 베르겐 대학교 학생들의 작업 덕분에 Temporal 구현이 빠르게 진전했습니다. 오늘날 temporal_rs는 모든 테스트의 100%를 통과하며, 이제 V8과 Boa 밖의 다른 엔진들도 지원합니다!
temporal_rs는 꽤 이례적입니다. 여러 엔진이 TC39 제안을 구현하기 위해 공유 라이브러리에서 협력하는 일은 드물거나, 전례가 없을지도 모릅니다. 이 작업은 성과를 냈을 뿐 아니라 대성공이었습니다. temporal_rs 덕분에 다음이 가능해졌습니다:
temporal_rs에는 Temporal이 Stage 4에 도달한 뒤에도 라이브러리를 계속 다룰 메인터이너 팀이 있습니다. 이는 개발자들에게 이슈를 제기하고, 버그를 보고하거나, 엔진을 이해관계자로 두고 직접 개선에 기여할 수 있는 안정적인 장소를 제공합니다.temporal_rs는 라이브러리로 범위를 한정했기 때문에, 엔진 전체의 맥락이 없어도 리뷰가 쉬웠습니다. 또한 내장 린팅(Clippy), 포매팅(Rustfmt), 그리고 엔진 대상으로 하는 CI 테스트 등 현대적인 Rust 기능을 활용합니다.
오늘 앞서 Temporal은 TC39 단계 절차에서 Stage 4에 도달했으며, 이는 다음 연례 ECMAScript 명세(ES2026)의 일부가 된다는 뜻입니다. 하지만 그때까지 기다릴 필요는 없습니다. 오늘부터 바로 사용할 수 있습니다!
Temporal은 이미 다음에서 지원됩니다:
Temporal에는 아직 할 일이 많습니다. 예를 들어 웹 생태계의 나머지와 어떻게 통합되는지 같은 문제를 해결해야 합니다. 수년 동안 웹 API들은 Date 객체와 함께(또는 이를 우회하여) 동작해 왔고, 그런 API들 역시 Temporal 객체와 호환되어야 합니다. 예시는 다음과 같습니다:
개발자들은 date picker에서 Temporal을 사용하고 싶어 할 것입니다. 지금은 불가능합니다(폴리필로 우회할 수는 있을지 모르지만, 오늘날 표준에는 아무것도 없습니다). Temporal 사용의 인체공학(ergonomics)을 개선해 나가면서, 현재 Date가 쓰이고 있는 영역에도 지원을 추가해야 합니다. 한 예는 datetime 관련 input 타입입니다. 아래를 보세요:
<input type="date" />
<!-- element.valueAsPlainDate -->
<input type="time" />
<!-- element.valueAsPlainTime -->
<input type="week" />
<!-- element.valueAsPlainDate -->
<input type="month" />
<!-- element.valueAsPlainYearMonth -->Temporal Instant가 나노초 단위까지 시간을 지원하기 때문에, DOMHighResTimeStamp가 사용되는 곳이라면 어디든 사용할 수 있습니다. 다음 예에서는, 보통 과거에는 DOMHighResTimeStamp를 사용했을 쿠키 만료 시간을 Instant로 설정할 수 있습니다.
cookieStore.set({
name: "foo",
value: "bar",
expires: Temporal.Now.instant().add({ hours: 24 }).epochMilliseconds,
});물론 이 밖에도 더 많은 것들이 있습니다. 분명한 것은, JavaScript 커뮤니티가 Temporal을 웹 플랫폼뿐 아니라 현재 Date를 사용하는 다른 모든 라이브러리에도 가져오기 위해 계속 열심히 작업할 것이라는 점입니다.
Temporal은 기업, 엔진, 개인을 아우르는 거의 10년에 가까운 작업의 결과입니다. 이는 다음을 의미합니다:
temporal_rs 라이브러리 형태로 드물게 나타난 공유 인프라의 사례우리는 수년간 Temporal을 위한 Igalia의 작업을 후원하고 지원해 온 것을 자랑스럽게 생각합니다. 그 투자와 열린 협업의 결합은 제안을 아이디어에서 명세로, 그리고 실제로 배포되는 현실로 옮겨 놓는 데 성공적으로 기여했습니다.
temporal_rs의 성공은 중요한 사실을 보여줍니다. 새로운 언어 기능이 엔진마다 중복된 노력을 의미할 필요는 없습니다. 공유되고 고품질의 오픈 소스 인프라는 비용을 줄이고, 일관성을 높이며, 웹 생태계 전반의 혁신을 가속할 수 있습니다.
Temporal은 단지 더 나은 API가 아닙니다. JavaScript 커뮤니티가 오래된 문제를 함께 해결할 수 있다는 증거입니다.
거의 30년 만에, JavaScript는 마침내 현대적인 datetime API를 갖게 되었습니다.
그리고 이번에는, 제대로 해냈습니다.
Jason Williams
Jason Williams는 Bloomberg의 JavaScript Infrastructure & Terminal Experience 조직의 시니어 소프트웨어 엔지니어로, Bloomberg Terminal과 웹 전반의 소프트웨어 성능에 집중하고 있습니다. 그는 TC39 대표(delegate)이며, 기능 표준화, 언어 구현, 대규모 오픈 소스 프로젝트 기여 경험을 갖고 있습니다. Jason은 또한 Boa JavaScript 엔진의 창시자입니다.