はじめに
本エントリは Life is Tech! Mentors Advent Calendar 2025 の 25 日目の記事です。
開発のきっかけ
僕は大阪金曜スクールで日頃活動しているのですが、先日メンバーの出席や目標の管理を行うための Web サイトをリリースしました。
この Web サイトでは、RFC 5545 という標準に則ったデータ構造でスクールの日程を管理しています。
RFC 5545 とは？
インターネット上でカレンダーやスケジュールに関する物事を表現するための枠組みを提案したもので、現代においてカレンダー関連の機能を持つアプリケーションや API は大抵これに準拠して実装されています。
カレンダーやスケジュールに関する物事、とは何でしょうか？
例えば僕が住んでいる区域で段ボールごみが出せる日は「第二・第四水曜日」となっていますが、この決まりはカレンダーやスケジュールに関する物事と言えます。
昭和二十三年法律第百七十八号
国民の祝日に関する法律
第三条 「国民の祝日」は、休日とする。
２ 「国民の祝日」が日曜日に当たるときは、その日後においてその日に最も近い「国民の祝日」でない日を休日とする。
３ その前日及び翌日が「国民の祝日」である日（「国民の祝日」でない日に限る。）は、休日とする。
国民の祝日に起因する休日は法律で上記のように決まっていますが、このような複雑なイベントもカレンダーやスケジュールに関する物事と言えるでしょう。
RFC 5545 は数多存在するこれらカレンダーやスケジュールに関する物事を可能な限り普遍的に表現可能な枠組みとして提案されているため、その適用範囲の広さと暦の解釈の難しさとが相まって、かなり複雑な枠組みとなっています。
さらに、これをグローバルなアプリケーション・API として実現しようとすると、タイムゾーンやサマータイムといった概念によって複雑度が跳ね上がります。
RFC 5545 は様々な言語・フレームワークで実装されていますが、このような事情によって RFC 5545 の定める標準全てに準拠するのを諦めたライブラリも少なくありません。
そのうちの一つが rrule.js という JavaScript ライブラリです。
本ライブラリは長らく JavaScript 環境における RFC 5545 実装を担ってきた歴史あるライブラリなのですが、RFC 5545 の複雑さと JavaScript の Date 型の扱いづらさによって*1プロジェクトが停滞してしまっています。
Furthermore, the RFC is extremely complex, with tons of edge cases, and a full implementation on top of a buggy Date primitive is going to be very expensive to build and to maintain. I would say that's the reason why this project has stalled for years and no replacement has emerged. At the end of the day, somebody (probably a large company) is going to need to sponsor a major effort to implement the RFC and maintain it on an ongoing basis.
https://github.com/jkbrzt/rrule/issues/450#issuecomment-1055853095
さて、例に漏れず僕の運用している Web サイトも rrule.js を採用していたのですが、前述の通りこのライブラリはメンテナンスが継続されていないため、不具合を踏んだ場合は元の実装を wrap するなどの力技で解決するしか手段がありません。
また、JavaScript の Date 型の扱いづらさや暗黙的な挙動にも苦しめられており、課題感を抱えながら日々フロントエンドを書いておりました。
Temporal API
そのような Date 型の問題を解決する新たな時刻管理用の API として Temporal API というものが開発されています。
個人的には長らく「実験的な API」、「未来の技術」という先入観があったのですが、実際はかなり対応が進んでいるようで、すでに Firefox では対応が完了しており、Chrome, Edge も 2026 年の 1/13, 1/15 にリリースされるバージョンでそれぞれ対応されるようです。
Chrome, Edge, Firefox などの主要ブラウザの対応が完了した後は JavaScript における時刻管理は Temporal API が支配的になっていくのではないかな、と期待しています。
Node-API
ところで oxc というプロジェクトをご存知でしょうか？
このプロジェクトは JavaScript 環境の Linter や Formatter などを Rust という言語で書き換えるプロジェクトです。
ここで詳しい話はしませんが、一般に Rust で書いた処理は JavaScript などのインタプリタ (や JIT コンパイラ) で書いた処理よりもパフォーマンスが優れるため、最近はスクリプト言語で書かれた処理を Rust で再実装する行いが流行しています。
さて、Rust で再実装するとは言っても Node.js ランタイムやブラウザが直接 Rust を読めるわけではありません。
ここでは、ネイティブ拡張と呼ばれる技術が用いられています。
これについても詳しい話はしませんが、Perl という言語のネイティブ拡張の話を 令和七年冬、DBD::mysql の quote メソッドを読む - ひむ日記 で書いているので、チラッと読むと雰囲気がわかるかもしれません。
Perl では XS というフォーマットによって開発者が Perl と C の呼び出し規則の違いを吸収する実装をしなくても良い仕組みが提供されていますが、Node.js では XS の役割を Node-API が担うことによってこれが実現されています。
この Node-API は公式には C や C++ 向けの実装が提供されているのですが、Node-API を Rust や Zig に拡張するプロジェクトも有志の OSS によって実現されています。
oxc などの Rust 製 JavaScript ツールは、Node-API という公式の仕組みとそれを Rust に拡張する有志の OSS (NAPI-RS) によって成り立っているのでした。
おわりに
そんな oxc と同じように、僕も Node-API と NAPI-RS の恩恵にあずかりながら Rust 製の高速な RFC 5545 実装を Temporal API 向けに提供する JavaScript ライブラリを作っているよ！という近況報告でした。
https://www.npmjs.com/package/chronical
Temporal API は、時刻を表現するフォーマットとして従来用いられてきた RFC 3339 を更新する標準である RFC 9557 が採用されていたりと、時刻管理の最先端を体験できている感じが面白いですね。
他にも Rust のオブジェクトを bundler に優しい形式で Node.js ランタイムに渡す方法など、いろいろ考え事があって楽しいです。
Star や不具合報告、Pull Request もじゃんじゃんお待ちしていますー！
github.com
お誘い
中高生の皆さんへ
Life is Tech! では楽しくプログラミングを学べる場を提供できるよう尽力しております。
キャンプやスクールで皆さんをお待ちしていますね！
camp.life-is-tech.com
life-is-tech.com
大学生の皆さんへ
僕たちと一緒に働いてみませんか？
一年に一回行われる Leaders という研修イベントに参加すると、技術的な事柄以外にもコミュニケーションやタスクマネジメントも成長できる上に、一緒に働けるようになるみたいですよ！
leaders.life-is-tech.com
*1:その他にもメンテナの方の業務内容の変化や慢性的なメンテナの不足なども要因として挙げられています
