Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

元号の改元日の境界処理

システム上の日付は、西暦でもたないとダメと断言してもいいでしょう。
とはいうものの、元号法が生きているので、画面上、帳票上は和暦を明記する必要があります。UI段階で変換すれば十分でしょう。
では元号はどこで処理するか、FrameWorkライブラリーやRDのミドルウェアーの元号モジュールで処理をしているケースが多いかと思います。いつになるか不明ですが、改元は必ず来ます。すぐ、ミドルウェアーが対応してくれればいいのですが、保証はありません。元号処理は自前で準備するのがGOODです。ではミドルウェアーの元号処理は信頼度はどうなのか。
 信頼度の線引きにもよるので、一概に言えません。いまだに昭和80年など昭和換算で処理しているシステムもあるわけですので。

DateTime.ParseExact(r, "ggy年M月d日", culture); で和暦の整合性をチェックできます。
昭和65年1月1日はNG...昭和の終了年超は押さえているようです。
昭和64年12月31日はOK...改元日は押さえてないのか。
平成1年1月1日 はOK.....改元日は押さえてないのか。
昭和1年1月1日はOK......改元日は押さえてないのか。
明治1年1月1日はNG......?なんでNG?
明治1年10月1日はOK.....?なんでOK?
境界点は明治1年9月8日でしてた。 この日は、明治に改元された日です。 なんで、明治だけ、改元日が考慮されているの?
しかし、コンピュータ上はの9月8日は太陽暦で処理されている。  明治1年9月8日改元は旧暦で行われているので、一致しません。
太陽歴に変わったのは、明治5年12月3日です。この時は、12月2日の次の日がいきなり、明治6年1月1日になりました。(体験はしてませんよ)つまり,12月は二日しか無かったのです。DateTime.ParseExact()は考慮されてませんでした。
 12月を一ヶ月飛ばしたのは、公務員給与を一ヶ月不払い(5年度の支給分)になるので、予算的に助かった...という都市伝説があります。真偽は知りません。何を血迷ったか、そのとき古い太陽歴であるユリウス暦を採用したため、明治31年にグレゴリオ暦に切替直したようです。このときも、一週間、存在しない日があったそうです。
西洋でもグレゴリオ暦に切り替えるときに、西暦1582年10月4日の次の日を、10日ずらして、10月15日としています。
 Oracleの日付関数はどのように処理しているのだろう。気になるところです。
 今の暦でも3300年に1日のずれが生じるので閏日問題が残っているようです。地軸のズレで公転周期もずれるでしょうから、そこまで考慮しても意味は薄いのでしょうが。
暦といえば月名がありますが、10月なのにOctober といいますね。octは8であり、蛸はOctpus です。もとは年10ヶ月制だった暦を12ヶ月制に移行にする際、時の皇帝の名前から、July,August が挿入され、「大の月でないとイヤだ」とゴテられた結果、7月・8月は大の月になり、その反動で、2月が二月が28日になったと伝えられています。
 天文学と暦は合理的なものなのに、運用面では、人間的な部分が多くて、面白いですね。
昔の出来事の当日は何曜日だと算出するアプリがありますが、暦が考慮されているのだろうか。
 もっとも、通常の業務アプリが大正以前の日付を扱うアプリは少ないと思います、資料管理や歴史研究アプリなら必要かも知れません。旧暦の誕生日の人の年齢計算が必要になったらどのように処理したらいいのだろう、換算テーブルで読み替えになるのかなぁ。作る局面はないでしょうが。

投稿日時 : 2008年7月30日 0:20

Feedback

# re: 元号の改元日の境界処理 2008/07/30 0:59 れい

> もっとも、通常の業務アプリが大正以前の日付を扱うアプリは少ないと思います、資料管理や歴史研究アプリなら必要かも知れません。旧暦の誕生日の人の年齢計算が必要になったらどのように処理したらいいのだろう、換算テーブルで読み替えになるのかなぁ。作る局面はないでしょうが。

結構これはいつも問題になってますよ。
論文なんかでも間違って計算してる人が多いです。

地域・地区と時代によって変わるだけでなく、
社会における階層によっても変わります。
官庁や聖職者は教会暦、経済はグレゴリオ暦、みたいな。

東欧なんかはつい最近までグレゴリオを使ってませんでしたし。

歴史的資料に書かれた日付がどの暦の日付なのかという解釈で揉めてたりすることもあるので…
特に偉い人は個人のポリシーの問題もあったりとかして。

暦それ自体が十分研究対象になるくらい複雑ですね。

人文的な問題だけでなく、天文学的な問題もあるんですよね。
閏秒の時は1[day]!=60*60*24[sec]なので、
「10年前の同日付同時刻の時から今日まで何秒か」
という問題は閏秒データベースに問い合わせないと分からない。

もうぐちゃぐちゃです。

# re: 元号の改元日の境界処理 2008/07/30 1:05 Pasie.

 本件について言えば、昭和最後の年は知っていても、最後の日は分かることが少ないからではないだろうか。昭和元年は12/25~ってのは分かるけど、さすがに明治や大正は覚えていませんし。

 明治の改元日以前は、それ以前にさかのぼると慶応だのなんだのと言う話になり、面倒だったからではないのでしょうか。

 まあ根拠のない勝手な邪推ですが。

# re: 元号の改元日の境界処理 2008/07/30 9:35 シャノン

「当社のシステムは内部的にも UI 的にも皇紀にしか対応しておりません」

# re: 元号の改元日の境界処理 2008/07/30 10:05 Ognac

コメントありがとうございます。
>論文なんかでも間違って計算してる人が多いです。
>という問題は閏秒データベースに問い合わせないと分からない。
>もうぐちゃぐちゃです。
東欧がグレゴリオ歴を使っていなかったとか、イスラムは、閏処理しない陰暦(ヒジュラ暦)で稼働しているなど、
どこの世界も、総論賛成各論反対的な反応と、保守的な行動をするので、同時に制度を変えるのは厳しいのでしょうね。
しかし、1週間を七日で区切る制度が共通化できたというのは、不思議な気がします。
侍の勤務体制は、三日ないしは四日単位で休みが合ったらしい。一週間七日制の導入で、勤務条件が悪化したと、不平続出したとも言われいます。(雑学本の出自で未体験です)
中国は西暦を受け入れているし、元号は廃止したらしい。日本は西暦を受け入れて且つ、元号は残している。
いかにも、日本人らしい、曖昧さを残したの対応と感じます。
 歴史の授業や歴史物で感じるのですが、歴史上の出来事をグレゴリオ歴で教えるのは、違和感一杯です、
関ヶ原の戦いは慶長5年9月15日であって、換算すると、西暦1600年10月21日になるそうです。それを 1600年9月15日と取れる教え方をするのは如何なものか。
赤穂浪士の討ち入りは、元禄15年12月14日です。換算すると1703年1月30日のようですね。こちらは、旧暦の日付を踏襲して、現在の12月14日としているのも多いようです。
1702年12月14日としているのもあり、眉唾的なものも目にします。
 歴史は、改竄する意志がなくとも、こういった事からも、違う意味で伝わっていく気がします。

>明治の改元日以前は、それ以前にさかのぼると慶応だのなんだのと言う話になり、面倒だったからではないのでしょうか。
Excel日付型が 1900年(1903年)から対応しているのはその為か?
Windowsの日付型のMinValue は 1/1/1/ だし、Oracle は-4712/01/01 ~ だし

都市伝説がさも事実化し、史実のように扱われたりするように、コンピュータの出力結果を盲信し、コンピュータの結果を堂々と公表していくうちに、既成事実化して行くのは怖いことです。
アプリに携わる者としても、心がけないといけませんね。

>当社のシステムは内部的にも UI 的にも皇紀にしか対応しておりません」

2月11日を元旦にしてます?....ってこれも、旧暦をどのように換算するかによって変わるんですよね。暦ってむずかしい。

# re: 元号の改元日の境界処理 2008/07/30 12:20 biac

改元日は… 昭和・大正ですらあやしいですから。
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=35637&forum=12&6
※ JIS X 0301 (1992) と JIS X 0301 (2002) で違います orz

明治6年1月1日以前の旧暦ってやつは… ずぇ~ったいに 関わりたくない世界ですしね~ f(^^;
ttp://bluewatersoft.cocolog-nifty.com/animecomic/2007/09/24_w_a2fd.html


> 「当社のシステムは内部的にも UI 的にも皇紀にしか対応しておりません」

はい。 内部的には皇歴を使わないと違法ですw
ttp://bluewatersoft.cocolog-nifty.com/blog/2007/07/re_7ae5.html


> 明治31年にグレゴリオ暦に切替直したようです。このときも、一週間、存在しない日があったそうです。

このときは連続していたはずです。
暦を切り替えたといっても、 1900年以降の閏年の算出方法を変更しただけですから。 ( 上の url の 明治三十一年勅令第九十号 )

# re: 元号の改元日の境界処理 2008/07/30 12:53 オムライス禁止!

>侍の勤務体制は、...(雑学本の出自で未体験です)
Ognacさんっていったい幾つw

で、2038以降はどうするんだろね。
#そのころ年金もらえるのかなぁ...

# re: 元号の改元日の境界処理 2008/07/30 14:32 Ognac

>JIS X 0301 (1992) と JIS X 0301 (2002) で違います
>明治6年1月1日以前の旧暦ってやつは… ずぇ~ったいに 関わりたくない世界ですしね~ f(^^;
うーん。混乱の極み。厳密に定義することが無理な世界のようですね。法解釈の問題も流動的でしょうし。
 仕事が来たら断ります。
>このときは連続していたはずです。
そうでしたか、ガセネタ発信してしまいました。お詫びします。

>Ognacさんっていったい幾つw
シベリア抑留経験者です。...違う!

明治31の情報はどこかで、仕入れた知識なのか出典をさがしたのですが、見あたらず。....都度出典を控えないといけないなぁと反省。....
本文中の、July/Augustの由来も、この二ヶ月が割り込んだためにズレたとする記事や、もともと、Marchが第一番目の月なので、octoberは8番目の月だから、おかしくないという記事もあります。Februaryの日数が少ないのは、最後の月だからとう記事もありました。
明治5年の12月の件は、閏月の設置前に変更したかったからという記事や、5年の12月の人件費と閏月の人件費を抑制したかったという、世俗的な記事もあり、真相は闇のなかなんでしょうね。
「真実は当事者しか知らない」というのか事実なのかもしれません。知識の伝承や、歴史書を作る難しさを感じます。

# re: 元号の改元日の境界処理 2008/07/30 21:08 RUN

>侍の勤務体制は、三日ないしは四日単位で休みが合ったらしい。一週間七日制の導入で

え~と、つまり
月月火水木金金
って事ですか?

… ダメだ、オチも何もあったもんじゃないORZ

# re: 元号の改元日の境界処理 2008/08/03 22:32 れい

> 関ヶ原の戦いは慶長5年9月15日であって、換算すると、西暦1600年10月21日になるそうです。それを 1600年9月15日と取れる教え方をするのは如何なものか。

実際の「日」か、それに名前をつけた「日付」か、という問題ですよね。

「日」を覚えるのに「日付」を使わないのであれば、「x日前」といった風に覚えないといけない。

実際に当事者や皆が覚えているのはその「日付」なわけで、なら当時の暦の日付になるのは当然かなぁ。

「1600年10月21日」というある時間領域が重要なのではなく、「9月15日」という「日付」が重要であると。

もしグレゴリオに変換して教えるのであればそれは歴史を尊重しない態度だと思います。
その時に生きていた人を無視してるかなぁと。

歴史で日付を扱う場合はほとんどの場合当時・現地での暦ですよね。
他の出来事との相関を見たいときだけグレゴリオな西暦ですが。

なので。

> 歴史上の出来事をグレゴリオ歴で教えるのは、違和感一杯です
歴史上の出来事は当時・現地の暦上の日付で教えてると思います。
なので関ヶ原の戦いは9月15日。
今後暦が変わったとしても、同時多発テロは9月11日でしょう。

# re: 元号の改元日の境界処理 2008/08/04 1:24 Ognac

>なので関ヶ原の戦いは9月15日。
>今後暦が変わったとしても、同時多発テロは9月11日でしょう。
赤穂浪士の討ち入りは、12月14日であり盆は7月15日。
記憶は、発生月日ですよね。賛同
その意味で言えば、関ヶ原は 西暦1600年の 和暦の 9月15日 と表示するのが正確なのか。
討ち入りは、西暦1703年の和暦の 12月14日 になる? まるまる1年ずれる誤解が生じそう。

そもそも、違う基準で設定されな値を換算するのが、無謀なのかも知れません。江戸時代の物価を今に換算したり、
戦前の生活を今に換算したりしてますが、環境の違うものを単純に換算できません。便宜上、換算しないと比較出来ないので、概略換算している程度でしょう。それを踏まえないで、鵜呑みにすると危険です。難しいものです。

# グッチ アウトレット 2013/03/08 23:05 http://gucci.kanpaku.jp/

こんにちは、またブログ覗かせていただきました。また、遊びに来ま~す。よろしくお願いしま%9

タイトル  
名前  
Url
コメント