SRFI-19実装がおかしい
nmoshのSRFI-19実装が微妙におかしい挙動を示していることに気づいてしまった。
SRFI-19は日付と時刻に関するSchemeのAPIで、Gaucheのような他のSchemeにもそれなりに備わっている。で、
$ nmosh nmosh top program nmosh> (import (srfi :19)) nmosh> (define d (make-date 0 0 0 0 1 1 1601 0)) nmosh> (date->julian-day d) Condition components: 1. &assertion 2. &who "/" 3. &message "division by zero" 4. &irritants ((0 0)) TRACE : 1 : ==USRP== (date->julian-day date) @ /usr/local/share/mosh-0.2.7/lib//srfi/19/srfi-19.scm:801 2 : ==USRP== (date->julian-day date) @ /usr/local/share/mosh-0.2.7/lib//srfi/19/srfi-19.scm:801 nmosh>
こういうふうに、西暦1601年1月1日をユリウス日に変換しようとするとエラーになる。
これは地味に困る。西暦1601年はWin32 APIのファイル日付(FILETIME)のepocで、nmoshのファイル日付取得で得られる日付は1601年からの経過ナノ秒で表現される。。そもそも、nmoshではPOSIX上ではまた定義が異なる値を返しているので、SRFI-19日付オブジェクトとの相互変換を目指した矢先に。。
今回は1601年のユリウス日をハードコードすることで事無きを得たけど、SRFI-19くらいはちゃんと実装を整備しないと。
この手の"よくわからない"日付の処理をユリウス日を中間表現として実装することは常套手段だけど、時刻の定義は色々と似たものが有って紛らわしい。今でもたまにTAIからUTCに戻し忘れてズレた時間を報告したりする。SRFI-19の場合は日付表現に型があるので、混ぜてもエラーにできるようになっている。