アカウント名:
パスワード:
増えるのかな。
って2020年からか。
2019年のカレンダーは天皇誕生日が存在しない（近代以降）初のカレンダーになる？
# そこはかとなくレア感w
2019年12月は「平成の日」になっちゃうんすかね。ついでに一回だけ前夜祭的に「皇太子誕生日」にして2月も休みにしちゃえばいいのに。
次の元号発表は何時になるんだろう、2019年明けてからかな。
それだと、カレンダーとか手帳とかの印刷業者からクレームが来そうだな・・・
2019年に改元するなら、2018年1月までに新元号は発表されているべきでしょうねえ。
というのも、2019年の祝日が確定するのは2018年2月なのですよ。だからそれまでに新しい元号や改元日が決まっていれば印刷業界の方は大きな影響は受けないはず。
なぜ2月に翌年の祝日が確定するかというと、祝日のうち春分の日と秋分の日は年によって変わるわけですが、この日付は国立天文台が作成する暦象年表の内容から閣議決定し、毎年2月1日の官報で公表するというプロセスで確定するそうです。だからそれまでは祝日が確定しないわけです。
参考：http://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html
そうか、その辺の印刷物になると前年から用意してないと作れませんね。流石に今回は周りを見回しながら計画的に色々すすめるんだろうなぁ。
イギリスだったら既にブックメーカーが張り切ってそう。日本だと、新元号記念レースとか宝くじとかやるのが関の山かな。
忘れてるかも知れませんがシステムもですよ。和暦対応のレジ、各種定期券等お金が関わるとテスト期間長いっす。
今時、内部処理まで和暦なんてことがあるのか？だいたい、テスト期間が長いなんてのは一般人の日常生活には関係ないので、説得力も何もなく、工夫して乗り切れ、というしかない。それに、常用漢字２文字であることと、（合字を使う場合）新規に作られる合字の文字コードさえ決まっていれば、事前にテストの大部分は開始できるだろう。
領収書とかの有効性に関しては、おそらく小規模事業者を中心に改修の設備投資負担に考慮するとかそういう名目で当面は読み替えが許されるような気がする。
一部だと内部通信プロトコルに和暦使ってるところも有りますので。面倒なのが内部処理じゃなくて、I/Fとレシートとか帳票の印字部分です。和暦ボタン(物理)が有るとハード改造もコミになったりしますし、旧暦と新暦を跨いだ場合の表記をどうするかみたいなシステム開発じゃない面での仕様決めが有ったりしてそれが長かったりします。
で、一般人はどうでも良くて、仕事でこういうシステムを開発・保守している人にとっては早く決めてもらわないと困るという話。定期券だと有効期限が印字＆大体最長半年ですから、2018年9月中旬(2019年4月1日の半年+二週間前から大抵延長可能)にはテスト完了して導入されてないと間に合わないですね。「新暦」みたいなダミーでテストして直前入れ替えで全帳票出力パターン網羅した成果物提出でなんとかなるのでしょうけど。# 西暦・和暦変換テーブルをOSとは別に持ったシステムをやってたりするのでAC
新暦決めるのもマ行タ行サ行ハ行以外とか色々しばりが有るから決めるの大変そうだねぇ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
2月の休日 (スコア:1)
増えるのかな。
って2020年からか。
Re: (スコア:1)
2019年のカレンダーは天皇誕生日が存在しない（近代以降）初のカレンダーになる？
# そこはかとなくレア感w
Re: (スコア:1)
2019年12月は「平成の日」になっちゃうんすかね。
ついでに一回だけ前夜祭的に「皇太子誕生日」にして2月も休みにしちゃえばいいのに。
次の元号発表は何時になるんだろう、2019年明けてからかな。
Re:2月の休日 (スコア:1)
次の元号発表は何時になるんだろう、2019年明けてからかな。
それだと、カレンダーとか手帳とかの印刷業者からクレームが来そうだな・・・
Re:2月の休日 (スコア:2)
2019年に改元するなら、2018年1月までに新元号は発表されているべきでしょうねえ。
というのも、2019年の祝日が確定するのは2018年2月なのですよ。
だからそれまでに新しい元号や改元日が決まっていれば印刷業界の方は大きな影響は受けないはず。
なぜ2月に翌年の祝日が確定するかというと、祝日のうち春分の日と秋分の日は年によって変わるわけですが、この日付は国立天文台が作成する暦象年表の内容から閣議決定し、毎年2月1日の官報で公表するというプロセスで確定するそうです。だからそれまでは祝日が確定しないわけです。
参考：http://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html
Re:2月の休日 (スコア:1)
そうか、その辺の印刷物になると前年から用意してないと作れませんね。
流石に今回は周りを見回しながら計画的に色々すすめるんだろうなぁ。
イギリスだったら既にブックメーカーが張り切ってそう。
日本だと、新元号記念レースとか宝くじとかやるのが関の山かな。
Re: (スコア:0)
忘れてるかも知れませんがシステムもですよ。
和暦対応のレジ、各種定期券等お金が関わるとテスト期間長いっす。
Re: (スコア:0)
忘れてるかも知れませんがシステムもですよ。
和暦対応のレジ、各種定期券等お金が関わるとテスト期間長いっす。
今時、内部処理まで和暦なんてことがあるのか？
だいたい、テスト期間が長いなんてのは一般人の日常生活には関係ないので、説得力も何もなく、工夫して乗り切れ、というしかない。
それに、常用漢字２文字であることと、（合字を使う場合）新規に作られる合字の文字コードさえ決まっていれば、事前にテストの大部分は開始できるだろう。
領収書とかの有効性に関しては、おそらく小規模事業者を中心に改修の設備投資負担に考慮するとかそういう名目で当面は読み替えが許されるような気がする。
Re: (スコア:0)
一部だと内部通信プロトコルに和暦使ってるところも有りますので。
面倒なのが内部処理じゃなくて、I/Fとレシートとか帳票の印字部分です。
和暦ボタン(物理)が有るとハード改造もコミになったりしますし、旧暦と新暦を跨いだ場合の表記をどうするかみたいなシステム開発じゃない面での仕様決めが有ったりしてそれが長かったりします。
で、一般人はどうでも良くて、仕事でこういうシステムを開発・保守している人にとっては早く決めてもらわないと困るという話。
定期券だと有効期限が印字＆大体最長半年ですから、2018年9月中旬(2019年4月1日の半年+二週間前から大抵延長可能)にはテスト完了して導入されてないと間に合わないですね。
「新暦」みたいなダミーでテストして直前入れ替えで全帳票出力パターン網羅した成果物提出でなんとかなるのでしょうけど。
# 西暦・和暦変換テーブルをOSとは別に持ったシステムをやってたりするのでAC
新暦決めるのもマ行タ行サ行ハ行以外とか色々しばりが有るから決めるの大変そうだねぇ