Not only is the Internet dead, it's starting to smell really bad.:2012年06月下旬

2012/06/30(Sat)

[NetBSD] LC_TIME

うるう秒ネタはなかった。

最近ではCygwinのLC_TIMEですら

$ date +%Ec
平成24年07月01日 00時17分29秒

のよーにまともに国際化されてるのでいい加減Nもstrftime(3)とstrptime(3)直さないとね。

んで最近やっと時間ができて *1ぼちぼち実装しとりまして、状況的には

[strftime]
実装 100%
テストケース 残
%g %G %l %s %U %V %W %z %Z %EC %Ey %EY
%Od %Oe %OH %OI %Om %OM %OS %Ou %OU %OV %Ow %OW %Oy

[strptime]
実装 残 %Z
テストケース 0%

という状況でございます、まぁLC_TIMEの実装についてちょっと悩ましい問題つーか
いつものmklocale(1)でlibEncoding持たないとERA/ALT_DIGITなんかのparseで困るよねという件
どうするか迷ってるので、commitに至るのはNetBSD時間になりそうですが…

ところでNetBSDのstrftime(3)のmanには

 BUGS
     There is no conversion specification for the phase of the moon.

とあるのに気づいたりして。

そもそもLC_TIMEというやつはカレンダーと時計を国際化するものではありますが
カレンダーについてはグレゴリオ暦に限定されておりまして、月の満ち欠けすなわち太陰暦はもちろん
排卵日カレンダーや「ぼくのかんがえる納期 2月1632日」なんてーに対応できないのは「仕様です」。
時刻についても標準時のみで「まだ38時か」とかOSS界に多く観察される廃人生活にも対応していません。

いわんやNetBSD時間!

論より証拠、日本すなわちja_JP localeの場合を見てみましょう。
わが日の本は島国(by 横浜市歌)では古来太陰暦を採用していたわけですが、明治5年11月9日に出された
太政官布告第337号により、明治5年12月2日の翌日(明治6年1月1日)を以てグレゴリオ暦へ移行しました。
ですので明治5年12月3日~31日というものは存在しません *2

んではPOSIX localeではこの明治6年以前の扱いはどうなっているのでしょうか。
まともにERAの実装されてるglibc2なんかでlocale -k eraしてみると

era="+:2:1990/01/01:+*:平成:%EC%Ey年";
"+:1:1989/01/08:1989/12/31:平成:%EC元年";
"+:2:1927/01/01:1989/01/07:昭和:%EC%Ey年";
"+:1:1926/12/25:1926/12/31:昭和:%EC元年";
"+:2:1913/01/01:1926/12/24:大正:%EC%Ey年";
"+:1:1912/07/30:1912/12/31:大正:%EC元年";
"+:6:1873/01/01:1912/07/29:明治:%EC%Ey年";
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"+:1:0001/01/01:1872/12/31:西暦:%EC%Ey年";
"+:1:-0001/12/31:-*:紀元前:%EC%Ey年"

と、明治6年(西暦1873年)より以前は太陰暦ですから扱えないので、元号ではなく西暦表示にフォールバックしています。

ですので明治以前の元号を扱えないのはマテガイだーとかいって 元号一覧あたりをソースにバグ報告したりしないようにね!

現代でもサウジアラビアではヒジュラ歴(イスラム歴)が公式の暦として使われていますが
POSIX locale においてはこれを扱おうと思ってもその術はないわけです、まぁこれ文字コードはすべて
Portable Character Set(≒US-ASCII)のスーパーセットであることが求められるような
しょせんメリケンさんのドメスティックOSを無理矢理拡張してきたことの弊害ですわな。

ですので、先ほどのNetBSDのstrftimeのBUG sectionもバグじゃないわけです。
ギャグとしても寒いので消しあsdfg

*1:お察しください。
*2:一か月の猶予もなしなので、SUICAに消費税率ハードコードで改修に最低1年必要なおまいらなら即死レベル。