アカウント名:
パスワード:
元号=(現在日 2019/05/01)?"平成":(判定日 2019/05/01)?"平成":"令和";※ただし判定日に過去日は入らない
今回打ち出された方針のキモは、プログラム的な例外判定は不要、というところでしょう。
ストーリーでは年度のことしか書かれてませんが、
各府省庁が4月30日までに作成する文書については、5月1日以降の日付も原則「平成」で表記する。
改元日以降も無効にならず「令和」には書き換えない。
というのが今回の閣議決定の重要なポイントかと。
4/30までは、元号データベースに令和が入ってない状態になっていて、それを元に処理するので、たとえば「西暦2019年10月1日」は「平成31年10月1日」になる。5/1になったら、元号データベースに令和が入るだけ。プログラムは変更なしで、「2019年10月1日」は「令和元年10月1日」表示になる。
「プログラム的には、元号データベースに基づいて処理するだけ」「5月1日、元号DBに令和を入れる」という対応だけで、> 元号=(現在日 < 2019/05/01)?"平成":(判定日 < 2019/05/01)?"平成":"令和";こんな、プログラムコード的な例外処理は不要。
あとは、年度の判定については、どの日を基準にするかの問題。来年3月31日までは今年度だから、単純に判定対象の日付から元号を計算するだけではだめ。どこかで例外処理する必要がある。実装として考えられるのは、・年度開始日である4月1日で固定判定→一番シンプルなルールなので採用が多そうですが、要改修・1月～3月は、前年13月～15月扱い→改修不要。でも、そんな実装あるかなぁ。・年度の中央の、10月1日で判定→改修不要。でも、そんな実装あるかなぁ。
おまけ:・元号データベースに年しか入ってない→年度判定だけなら改修不要(元号DB更新で自動的に令和元年度になる)ですが、2019年1月1日～4月30日の元号付きの表示に難があるので、日付単位で判定するように元号処理を改修しましょう。ぐらいですかね。
不敬の誹りを免れられないかもしれませんが、年度判定については、同一年度中に2回以上の改元が起きうることを想定している人がほとんどいないように思います。そこを想定するなら、「4月1日で固定」以外の選択肢は実用的ではないんじゃないかな……。
次の元号が「令和」にならない可能性もまだ1ppmくらいある。
言わずもがなだが敢えてコメント。
今上天皇のご退位は「2019/4/30 24:00:00(JST)」であり，この瞬間に以下のことが決定。 * 「2019/5/1 0:00:00(JST)」に「新天皇が即位」 * 「2019/5/1」及び「2019/10/22」を「国民の祝日相等の日とする」 伴って「4/30」「5/2」は「国民の休日となる」 * 「2019/5/1」より，元号を『令和』に改める。
> 次の元号が「令和」にならない可能性もまだ1ppmくらいある。つまり「平成３１年４月３０日が終わるまでに天皇がお隠れになられた場合」で，かつ「新たに決めなおした新元号が『令和』以外に決定された場合」ですね。
新天皇によって改めて「新元号はやっぱり『令和』とする法律」が公布されれば混乱は避けられるが，新元号の施行日をどうするのかまた揉めそうではある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
システム的には変わるほうが楽 (スコア:0)
元号=(現在日 2019/05/01)?"平成":(判定日 2019/05/01)?"平成":"令和";
※ただし判定日に過去日は入らない
Re: (スコア:0)
元号=(現在日 < 2019/05/01)?"平成":(判定日 < 2019/05/01)?"平成":"令和";
Re:システム的には変わるほうが楽 (スコア:1)
今回打ち出された方針のキモは、プログラム的な例外判定は不要、というところでしょう。
ストーリーでは年度のことしか書かれてませんが、
というのが今回の閣議決定の重要なポイントかと。
4/30までは、元号データベースに令和が入ってない状態になっていて、それを元に処理するので、たとえば「西暦2019年10月1日」は「平成31年10月1日」になる。
5/1になったら、元号データベースに令和が入るだけ。プログラムは変更なしで、「2019年10月1日」は「令和元年10月1日」表示になる。
「プログラム的には、元号データベースに基づいて処理するだけ」「5月1日、元号DBに令和を入れる」という対応だけで、
> 元号=(現在日 < 2019/05/01)?"平成":(判定日 < 2019/05/01)?"平成":"令和";
こんな、プログラムコード的な例外処理は不要。
あとは、年度の判定については、どの日を基準にするかの問題。
来年3月31日までは今年度だから、単純に判定対象の日付から元号を計算するだけではだめ。どこかで例外処理する必要がある。
実装として考えられるのは、
・年度開始日である4月1日で固定判定→一番シンプルなルールなので採用が多そうですが、要改修
・1月～3月は、前年13月～15月扱い→改修不要。でも、そんな実装あるかなぁ。
・年度の中央の、10月1日で判定→改修不要。でも、そんな実装あるかなぁ。
おまけ:
・元号データベースに年しか入ってない→年度判定だけなら改修不要(元号DB更新で自動的に令和元年度になる)ですが、2019年1月1日～4月30日の元号付きの表示に難があるので、日付単位で判定するように元号処理を改修しましょう。
ぐらいですかね。
Re:システム的には変わるほうが楽 (スコア:2, 参考になる)
不敬の誹りを免れられないかもしれませんが、年度判定については、同一年度中に2回以上の改元が起きうることを想定している人がほとんどいないように思います。
そこを想定するなら、「4月1日で固定」以外の選択肢は実用的ではないんじゃないかな……。
Re: (スコア:0)
次の元号が「令和」にならない可能性もまだ1ppmくらいある。
Re: (スコア:0)
言わずもがなだが敢えてコメント。
今上天皇のご退位は「2019/4/30 24:00:00(JST)」であり，
この瞬間に以下のことが決定。
* 「2019/5/1 0:00:00(JST)」に「新天皇が即位」
* 「2019/5/1」及び「2019/10/22」を「国民の祝日相等の日とする」
伴って「4/30」「5/2」は「国民の休日となる」
* 「2019/5/1」より，元号を『令和』に改める。
> 次の元号が「令和」にならない可能性もまだ1ppmくらいある。
つまり「平成３１年４月３０日が終わるまでに天皇がお隠れになられた場合」で，
かつ「新たに決めなおした新元号が『令和』以外に決定された場合」ですね。
新天皇によって改めて「新元号はやっぱり『令和』とする法律」が公布されれば
混乱は避けられるが，新元号の施行日をどうするのかまた揉めそうではある。