本ライブラリは古今東西あらゆる文化および言語で用いられた暦を表現し変換することを目指している Ruby 用のライブラリです。
| Rubyのダウンロード | http://www.ruby-lang.org/ja/downloads/ |
| 本ライブラリを用いたWebサーバの実装例 | http://hosi.org (ミラーサイト http://hosi-org.herokuapp.com ) |
| 本ライブラリを用いた日本暦注検索画面 | http://hosi.org/Note |
| 本ライブラリアーカイヴ一式 | http://www.asahi-net.or.jp/~dd6t-sg/date/when_exe_rev.0.4.6beta.zip |
| リソース辞書 | http://www2u.biglobe.ne.jp/~suchowan/ResourceDictionary.html |
| yardで作ったAPI仕様 | http://hosi.org/frames または http://www2u.biglobe.ne.jp/~suchowan/when_exe/frames.html |
| GitHub | https://github.com/suchowan/when_exe |
| RubyGems | http://rubygems.org/gems/when_exe |
| 最近の進展情報 | http://suchowan.at.webry.info/theme/a543700674.html |
基本的な目的は、古今東西あらゆる文化および言語で用いられた暦日・暦法・時法・暦年代・暦注などに ユニークな名前付けを行い、統一的に扱うための枠組みを提供することです。
またTZInfo や google-api-client と協働する点も特徴になるのではないでしょうか。
結果としてWebサーバーのエンジンなどに向くライブラリにはなったと思います。
Ruby にもともとついてくる Time, Date, DateTimeなどのクラスにくらべて桁違いに動作速度が遅く、 これらを置き換えるものではありません。
2016-03-18時点では、本ライブラリはβ版でrev.0.4.6です。
今後の課題については解凍アーカイヴ直下の<ticket>ディレクトリのtickets.xlsをごらんください。 ただし列挙された事項に実際に対策を行うか否かは今後の判断によります。
著作権関係は、最終的にはパブリックドメインに近いものにする予定ですが、まだ API など今後も揺れる可能性が残っており、 とりあえず現時点では次項のような強い制約のあるものにしています。
Copyright (C) 2011-2017 Takashi SUGA
You may use and/or modify this library according to the license described in the LICENSE.txt file.
You should use data sets TemporalPositionDataSet and TemporalReferenceSystemDataSet according to CC-BY-ND license.
You should use datasets described in /test/events according to each datasets' {dcq:license} link.
Ruby
1.実行環境
1.環境準備
2.irb
3.when.rb
4.railsデモ
2.APIの使用例
1.前提となる概念
2.逆引き
3.年号の扱い
4.時間間隔
5.剰余類
6.iCalendar
7.暦注
8.多言語対応文字列
9.標準クラスとの変換
A.初期設定
3.クラス図
01.Coordinates
02.BasicTypes
03.CalendarTypes
04.Ephemeris
05.RFC5545継承と包含
06.時間スキーマの構造
07.時間オブジェクト
08.時間幾何プリミティブ
09.RelativePosition
10.Duration
11.時間の位相
12.時間参照系
13.暦及び時計
14.時間座標系
15.順序時間参照系
16.時間位置のためのデータ型
ISO 19108 (JIS X 7108) の時間スキーマは、日付や時刻などの Temporal Position (より一般には、それらから構成される Temporal Objects) が、暦法や時法などの Temporal Reference System を参照する構造になっています。
本ライブラリは、Temporal Position などを When.exe Standard Representation (「1.日付時刻の表現」参照)で名前付け、 Temporal Reference System を International Resource Identifier (「2.国際化リソース識別子」参照) で名前付けして管理するという仕組みにしています。
本ライブラリを使用した Ruby on Rails デモプログラム http://hosi.org:3000 でインド太陰太陽暦のある日を表示してみましょう。
画面の最上部に、その日付のユリウス通日 2456952 に続けて、When.exe Standard Representation と International Resource Identifier を組み合わせた表現が表示されます。
Date[2456952]: 1936-07<13-^^HinduLuniSolar?note=HinduNote&location=(_co:Indian::Ujjain)&start_month=5&type=SBSA
表現は“^^”で２つの部分に分かれます。前半が When.exe Standard Representation、後半が International Resource Identifier の http://hosi.org/When/CalendarTypes/ (プレフィクス“_c:”)に続く部分です。
“1936-07<13-”は1936年7月黒分13日、“HinduLuniSolar?..”はBija補正ありのスールヤ・シッダーンタ方式でウッジャイン(http://hosi.org/When/Coordinates/Indian::Ujjain)の経緯度を基準にして計算した、年がチャイトラ月始まりのサカ紀元、月が新月終わりのシステムの、暦注としてパンチャンガをも計算するヒンドゥー式太陰太陽暦を意味します。
本ライブラリで扱う主なリソースの一覧は「リソース辞書」をご覧ください。
前項で例としたリソース“_c:HinduLuniSolar”は (2) Calendar、“_co:Indian::Ujjain”は (9) Spatial に記載しています。
暦相互変換プログラムwhen.exeは、 1990年頃に開発をはじめてもう四半世紀近くになるMS-DOSコマンドライン型ツールでした。 開発しながら暦の勉強をしてきたため、そのアーキテクチャはつぎはぎだらけで、改造や強化には向きません。 また、内部構造が汚くなっているため、UNIX や MacOS など他のプラットホームに移植したり、 ソースリストを公開して、そのアルゴリズムを社会に還元することもできません。 これまではプログラム自体に手をつけることなく、when.exe を検索ツールのエンジンとして tcl/tk や Web から使用するという方策でしのいできました。 しかし、Windows が XP->Vista->7 と進化するにつれ when.exe の動作環境が次第に失われ、 これらの方策もそろそろ限界にきています。
改版の機会は過去に2回ありました。
約20年前にプログラムを C++ で作り直そうとしました。C++ を選択したのは、暦は「互いに似ているが ちょっと異なる」というものが多く、オブジェクト指向でアーキテクチャを整理するのに向いているからです。 ところがデータを含めて約1万行近く作成したところで、自分が作っているのが、暦相互変換プログラムそのもの ではなく、その前提となる諸々の「しかけ」であることに気づいたのです。「互いに似ているがちょっと異なる、 今知られているものだけではなく、今後見つかるものも簡単に作れる」というアーキテクチャにするためには、 C++ は「しかけ」が不足でした。
約10年前にRubyで作り直そうとしました。前節で気がついた「しかけ」を Ruby の用語で示すと、
などです。Ruby に用語があるということは、これらの機能が Ruby にほぼ備わっているということです。 再度、改版にトライしました。しかし今度は、膨大なバリエーションになる暦の諸々の概念を ユニークに名前付けするという問題が解決しきれず頓挫 してしまいました。
そして今回の再トライです。
今回のきっかけは、名前付けを行う前提となる、諸々の国際規格が整ってきたことに気づいたことです。
ISO8601とRFC2445は(2)の時点で認識していたのですが、もっとも重要なJIS X7108がリリースされたのは、 ちょうど(2)が頓挫したころで、当時はその存在に気がつきませんでした。 今回の改版ではこれらの国際規格をベースとして過去及び現在存在するすべての暦を表現するべく改版を行っています。
ただし、本ライブラリの実装は参照した国際規格のそれぞれについて、過不足があります。
(*) 2001年の IETF 50th meeting@Minneapolis に参加して RFC 2445の議論を傍聴した際には 「複雑すぎてちゃんとした実装がない」という話題がありました。RFC 2445→RFC 5545は むしろ簡素化する方向への見直しと思われ、本ライブラリでの拡張が標準にとりいれられることはないでしょう。
テーマ「when.exe」のブログ記事をご覧ください。
