kozawa のたまに気になること

以下は途中で挫折しています。これを再利用してバージョンアップ版を公開するのは自由です（出典だけ明記してね、はあと）

まえがき

 本記事は主に PL/SQL の文法面について解説します。基本的に Oracle 11i の範囲内の文法について取り扱います。

PL/SQL の仕様

Oracleが独自に決めた言語です。類似の言語は幾つかありますが、PL/SQLと呼べるOracle以外のものは、IBM DB2 9.7以降に実装されたものだけだと思ってよいでしょう。

PL/SQL の実行 (CLI編)

PL/SQL で書かれたを実行するためにはCLIでOracleに接続して実行するのが一番手っ取り早いです。GUIベースのDB接続アプリ・開発アプリで実行する方法のも便利ですが、入門としては CLI イメージでよいでしょう。最短のHELLO WOLDをやる場合
CLIのSQL*Plusでログイン後、

SQL>SET SERVEROUTPUT ON
SQL>
SQL>BEGIN DBMS_OUTPUT.PUT_LINE('HELLO WORLD!'); END; SQL>/

の３行を入力します。 最短の実行要素は

SQL>BEGIN 実行したい内容 END;
SQL>/

通常は、読みにくいので、

SQL>
SQL>BEGIN
SQL> DBMS_OUTPUT.PUT_LINE('HELLO WORLD!');
SQL>END;
SQL>/

のように改行を入れて記述します。
※SET SERVEROUTPUT ONは、SQL*Plus上で標準出力表示を簡易に行うためのおまじないで、PL/SQLの直接の構成要素ではありません。このおまじないがないとDBMS_OUTPUT.PUT_LINEで出力が帰ってくる保証はありません。

上記は無名のPL/SQLの実行方法ですが、通常はPL/SQLのオブジェクトをDB内に生成して名前をつけて実行します。プロシージャ（戻り値なし）かファンクション（戻り値あり）のどちらかになります。

SQL>CREATE OR REPLACE PROCEDURE HELLO_WORLD()
AS
BEGIN
  DBMS_OUTPUT.PUT_LINE('HELLO WORLD!');
END HELLO_WORLD;

で生成して

SQL>HELLO_WORLD();
HELLO WORLD!
SQL>

で実行です。

基礎

PUT_LINE

言語仕様には画面デバイスへの入出力は定義されてませんので、標準パッケージDBMS_OUTPUTのPUT_LINEを使います。

コメント

 --から改行までがコメントになります。

-- コメント

文法チェック

ファンクションかプロシージャをCREATEする際に基本的な文法チェックがかかります。 論理的には文法チェックでチェックできそうなことが全部チェックできるというわけではないですが、基本的な文法構造を満たしていなければ実行できずにエラーが出ます。

文

文の最後にはセミコロン ( ; ) を付けます。

変数の宣言

変数名 型名

で宣言します。 宣言していない変数に代入することはできません。

数値

PL/SQLの数値型は、基本的に当該バージョンのOracleでサポートしている数値型と同等のものが使えます。

a NUMBER(2,1) := 1.1

数値演算

PL/SQLの数値演算はOracleのSQLにおける数値演算と同じ型変換が行われます。

代入演算子とインクリメント・デクリメント

代入演算子は以下１つで、インクリメント・デクリメントはありません。

a := 1.1

文字列

文字列はシングルクオート( ' )で囲みます。ダブルクオート ( " )は等価ではありませんので要注意です。

a CHAR(7) := 'abcdef';

文字列操作

文字列操作は、当該バージョンのOracleで使えるSQLに準じます。

結合

a := 'abcdef' || 'abcdef';
b := CONCAT('abcdef', 'abcdef');

分割

分割は簡単にはできません。Oracleの場合は、後述の検索のINSTR/INSTRBと切り出しのSUBSTR/SUBSTRB（文字を指定文字数で切り取る）を組み合わせましょう。

長さ

a := LENGTH('abcdef');

切り出し

a := SUBSTR('abcdef', 2); -- bcdef
b := SUBSTR('abcdef', 2, 1); -- b

検索

-- 見つからなかったら0が返る
a := INSTR('abcdef', 'b'); -- 2
b := INSTR('abcdef', 'c', 4); -- 0

配列
PL/SQLの配列的なものはちょっと癖があります。
結合配列(PL/SQL表)、VARRAY、ネストした表とあります。一番一般的な配列に近いVARRAYは

DECLARE
TYPE varray_char_2 IS VARRAY(2) OF CHAR(2);
varray_a varray_char_2;
BEGIN
varray_a := varray_char_2('element index of 1', 'element index of 2');
DBMS_OUTPUT.PUT_LINE(varray_a(1)); DBMS_OUTPUT.PUT_LINE(varray_a(2)); END; / element index of 1 element index of 2

要素の個数

varray_a.COUNT -- 上の例の場合 2

配列の操作

varray_a := varray_char_2('element index of 1', 'element index of 2');
// 先頭を取り出す
DBMS_OUTPUT.PUT_LINE(varray_a.FIRST); -- element index of 1
// 先頭に追加 ・・・はない
// 末尾を取り出す
DBMS_OUTPUT.PUT_LINE(varray_a.LAST); -- element index of 2
// 末尾に追加・・・はない
// 配列サイズを拡張
varray_a.EXTEND(1); -- COUNTが3に
// 部分コピーを得る・・・はない
// 一部を置き換える・・・はない
// 添え字の削除でtrimやdeleteがある。VARRAYは添え字連続の配列だが、
// 結合配列などでは添え字不連続で上述の操作可能。結合配列ではCOUNTとLIMITが
// 異なり、VARRAYは等しい

連想配列 (のようなもの)
・・・あったらいいなぁ。

制御文
if

IF 条件 THEN
　　HOGE();
END IF;

if-else

IF 条件 THEN
　　HOGE();
ELSE
HUGA();
END IF;

if-elsif

IF 条件 THEN
　　HOGE();
ELSIF 条件 THEN
HUGA();
END IF;

while

WHILE　条件　LOOP
　　HOGE();
END LOOP;

for

FOR　カウンタ変数　IN 　最小値..最大値　LOOP
　　HOGE();
END LOOP;
FOR　カウンタ変数　IN REVERSE　最小値..最大値　LOOP
　　HOGE();
END LOOP;

カウンタ変数は事前の定義は不要です（通常はむしろしてはいけない）。

loop

LOOP
　　HOGE();
END LOOP;

脱出条件が必要なら任意にIF等を使って記述します。
case
cとは違ってフォールスルーしない。IF-ELSEと等価。

CASE 条件
　 WHEN 条件 THEN
　　　　HOGE();
　WHEN 条件 THEN
　　　　FUGA();
　 ELSE
　　　　DOBON();
END CASE;

プロシージャ/ファンクション


ここで挫折続きがあるかどうかは神のみぞ知る

http://d.hatena.ne.jp/gifnksm/20100202/1265105961に後でトラバする

一部ではすっかり定着してしまったこの言葉。

ガラパゴス化 - Wikipedia に載ってるのはもはや驚かないが、 ガラパゴス化【ガラパゴスか】の意味 国語辞典 - goo辞書 提供元：「大辞林 第二版」 で「新語」に入っているのまで見てさすがに驚いた。

出典は、自力で探し出せなったので@takotさんに教えてもらったが、ITmedia エンタープライズ：日本におけるOSSの幻想――OSS界のガラパゴス諸島、ニッポンにある、OSDN Japan: Open Source Way 2004の初日2004年11月30日におけるセッション「日本におけるオープンソースの幻想とVA Linux」 佐渡 秀治 (VA Linux Systems Japan株式会社 マーケティング部 部長) (=kazekiriさん)だったと思われる。教えてもらったら思い出した。当時とても話題になって印象には残っている。こういう出典情報はwikipediaにも載っていなかったり案外忘れられやすいのかなぁなどとも思うけど、上記ITmediaの記事によれば、確かに彼はガラパゴス的という趣旨の発言をしたと思われるが、その単語を直接発したくだりは引用されていないし、「化」をつけた「ガラパゴス化」も記事に出てこない。当日のトーク全文と発表資料を比べてみたいものだと思う。最初に「ガラパゴス化」を使ったのは誰だろう？というのは継続して気になるのだけれども。最初はOSSの日本コミュニティのたとえで使われたのが、気づいたら産業・技術分野一般の話になって、その手の雑誌やTV番組でも珍しくない表現になってしまった、のか。

出典が別にあって私が知らないだけかもしれないのであまり断言はしないけど、こういう単語の広まりって後から調べようとしても既に失われていて近しい年代の単語でも「と思われる」「諸説ある」がよくあるので、調べないと気がすまない気質な人のためにあえてblogにここまで記しておくことにする。誰か継続調査よろしく（まて

自宅のPCが故障して（自分が悪いのだけど）困っていた所、ちょうど調べて見ると、こないだまで動いていたはずの自宅のNASの玄箱がおかしい。

HDDを別の玄箱に入れ替えて起動しても症状は同じ
・電源を入れると、赤ランプでエラー表示
・カタカタ音がする。

HDDデータ復旧サービスかな。と思ったけど高いし。でも、無料見積もりとかあるし、
日本データテクノロジー　データ復旧|PC・サーバー・RAID機器のハードディスク復旧ならデータ復旧.com
を使ってみた。
Webのフォームから問い合わせる。
データ復旧|PC・サーバー・RAID機器のハードディスク復旧ならデータ復旧.com

すぐに電話がある。でも、出先。「HDDの型番は？」とか聞かれてもわからんし。
「うちの営業時間はまだまだありますので、また今晩電話します」
と言われて一週間音沙汰なし。またWebから問い合わせ。HDDの型番も記入して
先日の続きと書きつつ先日と同じ内容を再度記入してWeb送信しようとしたら
・・・備考欄の文字数が多すぎるとはねられたorz
200文字くらいしか入れてないんですけど。
ひど。仕方がないので手短にHDDの型番とか前回不足事項を入れて送信。
外出した数時間後に電話が。同伴つき外出なので取り込み中。。。
で、説明する。が「OSは何ですか？」「どのPCにつないでいたんですか？」って玄箱って書いてる
んだから分かってよ、と言いたいが、まぁそれくらいは仕方がないだろう。
「HDDの容量は？」メーカーと型番書いたんだから
ぐぐればわかるはずですが。他にも色々症状を聞いてくるが、それって前回Webで書いて、その上電話でも説明した内容なんですが、確認なんてこれっぽっちもしてないですね。というか今回Webフォームで送った内容もかなり短いのに流し読みとしか思えないで「それ書いてありません？」「あ、あります」みたいな会話。
で、「外出先の用なので手短にお話しますね」と良いながら、くどくどと論理障害と複数の深刻度の物理障害の場合の可能性があって、それによって値段と期間と復旧可能性が違うが開けてみないとわからない、話を延々と丁寧にしてくれる。「そんな初心者名レベルの話はわかってます。手短にって全然手短じゃないですね」と苦言を言う。で「HDDの集荷をしないといけないんですが、番号とか今からメモ出来ますか？」ってえーと、今出先なんですけど、まぁメモ出来ますけど「メールじゃ駄目なんですか？」「メールアドレスを教えてください」ってWebフォームに書いてあるだろ。住所も聞かれて、Webフォームに書いたのを読み上げさせて「OK」と答えた。それだけのやりとりに15分以上。まぁ、メールは届いた。

帰宅後の時間を指定して、宅配業者から電話「今から伺いますが、住所は××でよろしいでしょうか？」「え、違います」って隣町の住所。大丈夫か、おい。宅配のミスかHDD業者のミスかわからんけど。その後集荷に来た。ちなみに、届いたメールには・・・送付先住所はあっても電話番号は書いてなかった。まぁ、なくても届くっちゃ届くけど、送付伝票には普通記入欄がある。宅配を常用してる業者だったら住所を知らせる時に電話番号も教えるって常識じゃないか？

というわけで、HDDの運命はいかに。

 김국현의 낭만 IT :: [낭만오피스] 스마트폰과 회식

まぁ、ベタでありがちなネタですが。台詞の翻訳不要な４コママンガ。

どこで誰がとは言いませんが実話です。
いつかは特定しませんが最近の話です。

古い機種になってしまいましたがEMOBILEのem one。不調時にバッテリーを外して指し直して再起動で直ることもよくあるのですが、それをやると、本体の時計設定がクリアされるようになってしまって。

まぁ、購入して２年よりだいぶたっての話です。なるのはしゃあないとしてWebサポセンに問い合わせると

・故障と思われます。ただし、TELでサポセンに連絡しないと集荷は絶対にしません

と冷たいお言葉。emobileのTELサポセンつながりが悪い経験が・・・。

TELして症状を伝えると

・リセットスイッチを押してください（二種類の二段階）
・それでもだめなら初期化してください
・それでも直らなかったら機械をみますので集荷します
・初期化がどうしてもできない場合は集荷できますが、必ずこちらでまず初期化します。必ず必要なデータのバックアップしてから送ってください

えーと、この手の機械で修理に出した時にメモリとかHDDとかを消してしまうこと（やむを得ずの場合とミスの場合と両方）はどうしてもあるので、それを否定するつもりはありません、が、普通に症状から推測して、初期化をしてからでないと機械的不具合のチェックをまったくやらない、というのはまったくもって不可解です。ま、修理側としても、レベルがピンキリのユーザに対するサポートという意味でも、その方が楽なのは非常によく理解できますが、へぼすぎると言ってさしつかえないかと。

 

                      SEA 名古屋 Forum  Feb 2010

                          テーマ「最新中国IT事情」
        　   --無錫オフショアシンポジウムから見えてくるもの--


                       主催:ソフトウェア技術者協会 名古屋支部

                     2/3 @ 名古屋国際センター・研修室

                                 参加者募集


  無錫政府の主催で、江蘇省無錫オフショアシンポジウムが2009年11月に開催されました。
このシンポジウムでは、講演と現地見学が行われ、現地見学は、いろいろな開発区をバスで回って
拠点オフィスを見学するというものでした。見学先には、SunのOpen Source Innovation Center, 
IBM Cloud Computing Center などがあったとのことです。
  今回のSEA名古屋フォーラムでは、このシンポジウムに実際に参加された、SEA上海支部の
杉田義明さんをお迎えし、シンポジウムの概要、開催の背景となっている中国のIT政策や、その
現実、SEA上海での関連フォーラムの内容などを紹介していただくとともに、ご自身が体験されて
いる中国でのITビジネスの話題を提供していただき、参加者ともに討論したいと思います。

 中国で仕事をしたい方や起業を考えている方、その他中国ITに関心のある方々の積極的な参加を
お待ちします。

 *****************   開 催 要 領   *****************

 1.日時:2010年 2月 3日(水)  18:15受付, 18:30開始, 20:30 終了

 2.プログラム(予定)

   18:15 - 18:30 受付
   18:30 - 19:30 開始
                 講師: 杉田義明  (福善上海 Fukuzen　Co.,)
   19:30 - 20:20 オープン・ディスカッション
                  パネル・メンバーを含めて会場全体での討論
   20:20 - 20:30  クロージング
                  次回予告など

 3.会場: 名古屋国際センター・研修室(3F第2研修室)
        名古屋市中村区那古野一丁目47番1号
       (名古屋市営地下鉄 桜通線・国際センター駅直結)
        http://www.nic-nagoya.or.jp/japanese/aboutus/access.htm

 4.定員: 20名

 5.参加費:SEA正会員 500円,SEA賛助会員 1,000円,一般 1,500円
    参加費は、当日会場の受付で受付番号とお名前をお申し出の上、
    現金でお支払いください. 
    領収書をさしあげます.

 6.申込み方法: 下の申込み票に必要事項を記入してSEA名古屋支部フォーラム受付
           sea-seminar @ forums.gr.jp
    まで、E-Mailでお申し込みください。
    折り返し、受付確認の mail をお送りします. 
    申込み後のキャンセルはご遠慮ください.
    (何らかのご都合で参加が不可能になった場合は代理をお立て下さい.)

  テキストメールでお申し込みください。また、1メールにつき、1名の申し込みでお願いします。

  参加申込み票  (申込先:E-mail: sea-seminar @ forums.gr.jp 

  SEA 名古屋 Forum  Jan 2010 (2/3 @名古屋国際センター) 

  ご氏名:__________________ ふりがな(______________________)
  E-mail: _____________________________
  参加種別(いずれかにチェック・記入ください): 
    □ SEA会員(No:     )
    □ SEA賛助会員 (会社名:               )
    □ 一般
  領収書のあて先:_____________________________

     *注:賛助会員企業一覧:http://www.sea.jp/sanjo.txt

http://sea.forums.gr.jp/nagoya/

2010/1/13(水) 18:30より国際センターにて。

                      SEA 名古屋 Forum  Jan 2010

            新春放談〜ソフトウェア技術の今まで、これから〜

パネルプレゼンテーション１ 30分
石川さん　要旨はソフトウェアの保守・運用は「進化」へと変化する。
保守・運用というおまけ、負のイメージはおかしい。保守は活用されていない。
保守を活用すれば開発済みソフトウェアは進化して付加価値をさらに生み出す、とまぁ
乱暴にまとめればそういうことかと。
そういう大きな方向性の提案というか予想は前向きで割りと賛同できる。

といっても、放談に細かい突っ込みも無粋だが、色々な論点がごっちゃになってるので
気にはなる。ハードウェア等の有償保守契約をユーザが使いこなしてないのはユーザの
問題でもあるが、それは体制の話？無償サポートも充実する方向にある話も出たが、
CRM的なサポート向上（マス的商品に顕著）と、ブランドとしてのサポート向上（個別開発
にも適用可能、OSSやコミュニティのようなものにもつながる）等々色々ある。
受託開発で保守の中から新しい提案をみつけてきてソリューションにつなげるという
のは昔から求められていること。そういうのを同様にマス的ソフトでやるのは可能なのか。
逆にFirefoxなんかは、トップダウン的に上層部がビジョンを持って仕様を決めるので、
バグは直すにしろ、仕様追加はあまりエンドユーザの言うことを聞くつもりはない。
MS-Officeなんかはかなり大規模なアンケートを取ったようだが。
＃日本人はExcelの印刷プレビューの頻度がアメリカより高い、だからプレビューボタンを
＃使いやすくした、などというプレゼンを見たことがあるが、元々いい位置にプレビュー
＃ボタンはあるのだし、Wordで実現できているWYSIWYGが不十分でプレビューしないと
＃印刷が切れることが根本問題なのだからそこを直せよと小一時間。

パネルプレゼンテーション２ 30分
田村さん 2010年だし、2001年の10年後予想を振り返って。
まぁ、あんまり語ることはないけど、予想の当たったところも外れたところもあって、
いずれにしても今の技術動向は面白いよねと。
「2010年の10年後予想は」と言われて「無理」と断った田村さん。世界の変化の例で、Youtubeでも話題の動画【日本語訳】Did you know 3.0 〜あなたは知っていましたか？なんかも紹介。4.0などもおもしろい

パネルプレゼンテーション３ 30分
岸田さん
ソフトウェアと美学の話題。インストラクション・デザイン(ID)の話題から、
各種ソフトウェア開発論、ソフトウェア論文に話が移って、「美しい開発」へ。
その「美しい」は岸田さんのもう一つの専門のアートの話とも絡み合って
作品の意味は作り手とも受けてとも切り離されて存在するようなアートを
目指したいという話から（まぁそれはそれで現代美術の一潮流ではあるけど、
最新ではないなぁとか思いつつも、おもしろいジャンルではある）、
意味を切り離されたソフトウェアとはありうるのかと話が発散する。
まぁ、アート作品としてソフトウェアが使われて、機械的に生成された
映像なりなんなりといいう美術ジャンルはあるけれど。
実用ソフトだけど意味定義不能といったものが成立するか、
というのはアーティストが挑戦して、成功を待ちたいという気はしなくも
ない。まぁ、作り手の予想や周囲の予想と違う発展をソフトウェアが
やることというのはままあって、そういうのも関連分野と見ることはできない
かな？予想できないから世の中は面白い。解釈が多様だから
世の中は面白い。

放談なので、クラウドの是非とかtwitterのあり方とかSNSの変遷とか
その後は色々話題が飛んでいったんですが、雑談としてはなかなか
面白かったかと。

0.7.10からしばらく静かに見えていたKompoZerの0.8b1が出たのが2009-10-11？ 日本語l10nがちょっと遅れててkazé(Fabien Cazenave)が日本語関係者にヘルプ！って11月上旬にやってたけど、私はちょっと動けなかったんだけど、経緯はわからないけど、11月の月末までには対応してくれた人がいたようで、今は KompoZer - downloads からダウンロードできるようになりました。 see also KompoZer 0.8 localized builds - Kaz'hack 相変わらずここも、存在価値について賛否両論あるでしょうけど、Donate募集中なので よろしくです。 そういうえば、一時の円高基調がちょっと戻っているようです。 でも、USからMozillaグッズを買うなら円高のうちがいいですよ。是非是非。

システム開発で、元号と西暦を変換する機能を実装するというのをちらほら見かける。 大抵は、明治時代くらいまでさかのぼればいいだろうってことで、OKにされているが、勝手実装は大抵間違っている。 先日、2009/11/1頃にOpenOffice.orgの日本のfreemlのメーリングリストで 「[openoffice:11788] 西暦と和暦の変換が正しくない」でスレッドが立ったので思い出した。 そのスレッドの内容も勉強になったのだけれども、 和暦、西暦の年月日対応に関する注意点 西暦和暦 年月日対応表(月の日数、閏月)【西暦和暦変換用データ】 に割と参考になる情報・データがあるけど、これも完全じゃあないけどまあいいとして。 こういうのをコーディングしたフリーのコードとかどっかでやんないのかなぁ、などと。

元号・西暦変換は、明治６年以降＝1873年以降は、そのまま元号と西暦を変換して、改元の日だけ気をつければ 実用上問題はないといっていい。が、それ以前は要注意。日本で元号による年月日表現と言えば明治５年までは「旧暦」だった。 明治5年12月2日は1872年12月31日。明治5年 - Wikipedia。 や、世の中ではその辺ちゃんと扱われてない年月日情報も氾濫しているし、無知ゆえに、もしくはわかっていて 年＝グレゴリウス暦基準、月日＝太陰太陽暦基準、な表記や年＝太陰太陽暦基準、月日＝太陰太陽暦基準グレゴリウス暦基準 をしている場合も多々ある（どちらかの表記に年だけ元号/西暦変換で参考につけてあるとかならわからんでもないけど、 正しい変換は素人には難しいので素人が書いた情報はどちらにしろあてにならない。もちろん私も素人）。 MS-Excelさんは1900年までしか変換に対応していないのでこの変換を逃れているが、OpenOffice.org Calcはなまじもっと前まで対応しているので明治５年以前で問題を抱えているし、そもそも明治より前だとただたんにバグになっている。 変換は、各元号の開始と終了の年月日さえわかっていれば機械的に変換できると思う人もいるかもしれない けれど、「閏×月」といったものが旧暦にはある上、同じ太陰太陽暦といっても、日本の正式な暦では 太陰太陽暦 - Wikipedia 何度か計算方法が改定されているので、機械的にやるのはかなり難易度が高く、きっと今時は変換表を中に 持つほうが早い。日本がグレゴリウス暦を入れてから以後は機械変換でいいとして。。。

ちなみに、OpenOffice.orgはご丁寧に、ユリウス暦からグレゴリウス暦への変換も対応してくれている。 オートフィルでCalcで1582年10月1日からやってみると、変換に対応しているのがわかる。 がこれも「すばらしい」と一言で言ってよいかどうか。いわゆる西暦採用国でも、国によってユリウス暦から グレゴリオ暦へ変わった時期も違うという問題があるという。機械処理で暦の切れ目を無視して使いたい時 なんかもあるかもしれない。i18nな観点から言うと、ロケール毎にデフォルトを決めた上で、ユリウス暦と グレゴリオ暦を明示的に変換できるようにしたり、ロケール指定の変換も出来るようにした方がよいのかも しれない。同じロケールの中ではデフォルトは西暦は１つの暦にすればよいか。まぁそういうことを言い出すと、 日本の旧暦以外のさまざまな暦に対応する必要も出てくる。同じような旧暦の類でも、中国と日本では微妙に 日付が異なっている（元号ももちろん違うが）。暦の計算方法の改定が中国起点でそれを日本が遅れて 取り入れていたり色々事情があるので仕方がない。中国のそれも入れるのかどうなのか。 日本だけ見た時も、どうも元号が始まったのは「大宝」からという説が有力そうだけれども、それ以前は とか言い出すともうカオス。南北朝時代の元号分裂はどうするんだとかはてさて。ここに正攻法で突入すると 非対称変換も考慮に入れる必要が出てくるのか？ というか、M/T/S/Hの表記方法だと慶応以前はどうするんだろう。慶応はK？ まぁ、大抵の情報システムではせいぜい生年月日でいいので、明治６年以後だけ扱えればこと足りるはず なんだけども、以前「企業の創立年月」まで変換を入れようとしていたのを見たことがあるがはてさて。 現存する日本最古の企業と言われる金剛組は578年創業って当時は日本にまだ元号が取り入れられる前… ですねぇ。私は当時の暦には詳しくないんですが、元号以前は日本では（？）干支を使った年の表記など がなされていたりしたようですが、どう変換すればいいんですかね？ と上記ごっちゃになってますが、月日の変換問題（暦の問題）と元号の問題は本質的には多分別です けど、機械変換すると両方同時にやらないといけないんですよね。
するとライブラリみたいにソースに落とす話に戻すと、西暦はいいとして和暦はどういう型に持てば いいのか。。。言語ごとに決める？変換インタフェースは、
foo = GengoToSeireki(元号, 変換後暦（グレゴリウス暦かユリウス暦か等、もしくはロケール、省略可）
 みたいなのになるのか？うーん？？？ 元号っていう文言をインタフェースに入れてしまうのは中立じゃないような気もするし。
＃上に自分で書いた暦と元号は別問題というのとも矛盾
旧暦に手を出すと現在の旧暦変換も手を出したくなるけどそれこそ機械変換が無理で誰の発表する情報を使えばいいかも厳密に決めづらいのだとか。

ちなみに、関連話題でタイムゾーンの問題もあって、こっちは普通は同時には扱われないのだけれども。 同時に扱ったらどうなるやら。普段「1432年5月2日に何々がありました」などというときにタイムゾーンを 意識することがあるだろうか？通常しないのだけれども、必要な場合とそうでない場合をどうやって 切り分ければいいのか？はてさて。

まぁ、世間が厳密じゃないところに厳密なものを作る意義ってどれほど？なわけですが、あったらいいな とは思うものの紛糾するばかりで実装できそうにないなぁ、などと。こういう時こそコードを書いたが勝ち なんだろなぁ。

補足：妄想の上記ライブラリの話はおいといて、現実的には「明治６年以降だけ対応する」「間違っているのを承知で明治元年から対応する」あたりになるんでしょうな。それ以前に手を出すともうかなりなみだ目。ちなみに言えば、韓国なんかじゃいまだに誕生日は陰暦で祝う習慣も残っていたりするなど世界を見るとやっかいなネタはごまんと眠っている。

 Amazon.co.jp： IT立国エストニア―バルトの新しい風: 前田 陽二, 内田 道久: 本

エストニアのIT戦略を紹介。（最初に国の紹介も多少）。
本書だけ読めばとてもうらやましくなる。インフラ普及、行政システムのIT化、などなど。著者もいいねぇ。覚えておこう。