[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[openoffice:11808] Re: 西暦と和暦の変換 が正しくない



小笠原です。


まず、ソースコードを見て云々から ML 退会どーのこーのは言葉が
過ぎました。誠に申し訳ございません。
確かにただ issue を投げてもほぼ間違いなく日本人以外は(そして、
ほとんどの日本人も)どう直せばいいか分からないですからね。

#ただソースコードによらず正しいアルゴリズムを示すことはできる
#はずで、いきなりソースコード読んでくれ、はちょっと乱暴ではな
#いかと思うのです。開発コミュニティなら別ですが。


回線が細いとのことで私の意見を簡単にまとめます。

・明治5年の暦切り替えに対する Calc 自体への対応は不要。
 - 理由は労多くして酬われないため。
・ニーズがある程あれば、マクロなどを日本コミュニティで提供する。


以下は回線が太いところで読んでいただければ結構です。
---------------------------------------------
ということで真面目にソースは追ってませんが、チラ見した程度で。
そもそも gengou_eraArray[] (in calendar_gregorian.cxx) に明治
・大正・昭和・平成しか入っていない時点で、それ以前の元号の変
換は考慮されてないことが分かります。
ので、「ちゃんとした」暦変換を行うべきかどうかがそもそも問題
になると思います。全部の元号を変換した方がよいかどうか。それ
をせずして「完全な」和暦変換はありえないでしょう。


それからこのスレッドで話題になっているのは、西暦 <-> 和暦変
換において、明治5年(=1872年)の太陰太陽暦から太陽暦への変換
のため12月が2日しかなかったという事実に対応するかどうかだと
思いますが、ソースを見渡した限りではこの対応は入っていない
……ですよね。

で、どうせ明治より前(慶応以前)の元号はサポートしてないし、
太陰太陽暦のサポートはすごく大変なので、中途半端に
  1872/12/7 -> ×明治5年12月7日 -> ○明治6年1月2日
という変換に対応するためにコストを払うのはムダというのが私
の考えです。
大変である理由は:

- 年だけサポートしても、月がずれては意味が薄い。
- 月をズレなくサポートするには閏月のサポートが必須。
- どの月に閏月が入るかはアルゴリズミックに変換できない訳では
 ないが(※)、時代によってアルゴリズムが異なるのでその変換
 式を間違いなく導入しなければならずコスト(主にテストの)が
 高い。
ー 割に、得られるメリットが非常に少ない。

(※)過去のメールでできないと書いたのは間違いです。「計算機
がない昔は非常に一部の人しかできなかった」ですね。


ので、Calc 本体での太陰太陽暦→太陽暦切り替え対応はすっぱり諦
めて、欲しいという人が多いなら、日本コミュニティで変換マクロ
でも作って公開したほうがいいのでは?というのが私の意見です。


# 枝葉だけど、calendar_gregorian.cxx というファイルの中に
# いくつかのサブクラスの実装があるのは微妙だなぁ……。
# calendar_gengou.cxx というファイルに元号/和暦関係の処理が
# まとまってればずいぶん読むのもラクなんですが。

[以上]
-- 
Naruhiko Ogasawara (naruoga@gmail.com)


【MLコミュホームページ】http://www.freeml.com/openoffice

--[PR]------------------------------------------------------------------
◇◆◇◆        憧れの4LDKや共用施設充実マンション     ◇◆◇◆
◆◇◆◇賃貸じゃ難しい?理想の住まい探しは早めの資料請求で先手!◆◇◆◇
◇◆◇◆  これから販売予定のおNewなマンション、即チェック    ◇◆◇◆
http://ad.freeml.com/cgi-bin/sa.cgi?id=eIrjz
------------------------------------------------------------------[PR]--
■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp