中央省庁の行政システム、日付の記録に西暦を使用する方針へ 99
ストーリー by hylom
DBのテーブルはどうなっているのだろう 部門より
DBのテーブルはどうなっているのだろう 部門より
政府が各省庁で使っている行政システムでは、現在西暦と元号のデータが混在しているそうだ。しかし、この元号で管理するシステムでは改元の際の改修コストが高いという問題があった。そのため、今後各省庁の行政システムにおいては原則として日付データを西暦で管理する方針にするという（読売新聞、時事通信）。
こういった動きは中央省庁だけでなく、地方や民間企業でも進んでいる。たとえばJR東日本は昨年12月から3月にかけて切符に印刷する発券日を西暦に切り替えている。さらに首都圏の私鉄各社も切り替えを行っているという。
また、京都府内では転入・転出届などで日付を西暦で記入できる様式が広まっているという（京都新聞）。佐賀県でも本年度から公文書の一部で西暦を併記しているというが、和暦を完全に廃止するという動きはないようだ（佐賀新聞）。
ありがとう自民党の保守派と宮内庁 (スコア:5, おもしろおかしい)
君たちが公表をギリギリまで引き伸ばすため全力を尽くしてくれたおかげで西暦移行の大義名分が立ったよ
新元号に移行しないのであれば、西暦移行まで平成を使い続ける [it.srad.jp]のもまあアリだな。
Re:ありがとう自民党の保守派と宮内庁 (スコア:1)
まじで元号の緩やかな廃止を目論んだ施策なんじゃないかって思えてきた。
Re:ありがとう自民党の保守派と宮内庁 (スコア:1)
昭和100年問題が迫ってやむを得ず変更するんじゃね？
Re: (スコア:0)
むしろ最初からこれを狙ってたんじゃないか？
と思えてきた
西暦元号変換 (スコア:2)
今は2012は24年だったなで計算してる
12が24で覚えやすかったから
Re:西暦元号変換 (スコア:2)
発想としては12時は24時
Re:西暦元号変換 (スコア:1)
１ダース追加で良くない？
Re: (スコア:0)
確かダースだから・・・カーネル３ダースで３６足せばいいのか、と勘違いしそうだ
Re: (スコア:0)
確かダースだから・・・カーネル３ダースで３６足せばいいのか、と勘違いしそうだ
カーネルダンプで12取れましたので残り24です
Re: (スコア:0)
1988(平成0年に相当)の方が覚えやすくない？
8だけ覚えとけば、あとの数字は簡単に補完できるし
Re: (スコア:0)
Re: (スコア:0)
今後は2012は12年に変換するから楽勝だなっ
Re: (スコア:0)
昔、そろばんやってた時に、8月8日がパチパチでそろばんの日と設定されていて
西暦から88引いた下2桁が平成の年だと習ったわ。
2018 - 88 = 1930 → 30年
Re:西暦元号変換 (スコア:1)
そろばん界隈にそういう理論があるのが面白いね。
平成元年は西暦1988年なので、現在の西暦から1988を引けば平成の年が出るというのは当たり前だと思ってた、
2018 - 1988 = 30
Re:西暦元号変換 (スコア:1)
すみません、" - 88 = -89 + 1" ですね。
#遠い記憶・・・
本当に西暦で持つの？ (スコア:2, すばらしい洞察)
どのレイヤで「西暦に統一したる！」と言ってるのかよく分かんないけど
DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。
いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
検索やソートの速度もわりと問題無かったし。
でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。
Re: (スコア:0)
決定権持ってる人がデータ形式なんて理解できるわけないじゃない
手書き紙ベースで出来るのになんでできないんだとしか思ってないよ
下は上に具申する権限すらないので朝令暮改もありうる
Re: (スコア:0)
キャリア官僚系は課長補佐クラス（30代くらい）が事実上の決定権を持っていて
課長より上は決裁権はあるけれどほとんどのことについては
事実上ハンコ押すマシンだ、と聞いたことがあるけれど
Re:本当に西暦で持つの？ (スコア:1)
元請SEより上はエクセルに線を引くマシーンじゃないの
# なお両者とも決定権はない
Re: (スコア:0)
決定権を持つのは顧客です！
#なお客先担当者に決定権はない
Re: (スコア:0)
そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。
Re: (スコア:0)
手書きの内容をそのまま保存（）が原因
→文字列保存。
だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。
さらに打ち間違い言うか見た目だけで「ﾆ」
（半角カナの「に」）を2として入れてたり。
だが処理時には正しい日付としてちゃんと処理しろ（）なんだよね。
Re: (スコア:0)
通達
開示請求で公開しない文書は13月以降の月日とする
Re: (スコア:0)
DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。
若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。
もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・
そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。
特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。
データの記録形式の話と、表示の話が混在？ (スコア:2)
省庁がデータを西暦に一本化するというのは、記事を読む限り、内部での記録形式のことのようですね（今まで、省庁によっては元号方式での記録をしていたという事も驚きですが）。
一方、切符の印刷の話は、タレコミ文章やググった記事 [jiji.com]を読む限りでは、（記録データが西暦かどうか不明だが）少なくとも表示は西暦にすると読める。
Re: (スコア:0)
元号で持つと二千年問題がないんですよ。どやぁ！
というか、二千年問題対応時分に聞いた話だと、あれは二桁で持ってた故の問題だったわけですし、
汎用機時代からCOBOLで連綿と処理してきたデータだとそんなもんじゃないんですかね。
他に皇紀でもってるから大丈夫みたいな話も聞いたことあるし、データストアもRDBとは限らんわけだし。
Re: (スコア:0)
皇紀ってまだ使ってるんですか？
神社なんかには皇紀～年って書いてあった気がするけど。
歓迎 (スコア:1)
廃止しない方針なら、元号を「そんなもんあったねえ」くらいのものにしてしまいましょう。
学校では日本史の年号も西暦で覚えるし。
Re: (スコア:0)
こういう考えが普通に出てくるのが
戦後教育の賜物だな
自国文化を軽んじるのは若さゆえか、
それとも単に自国民じゃないだけか
Re: (スコア:0)
別に元号は文化でもなんでもないと思うんだが。
Re: (スコア:0)
どうせ元号なんて中国かどこかが発祥の文化だし。
Re: (スコア:0)
尺貫法を捨てたときも「売国奴」「文化を大切にスべき」論者が湧いてきたと推測する
Re:歓迎 (スコア:1)
Re: (スコア:0)
腹がふくれるふくれないで判断すりゃええのよ。
銭にならない文化()なんて保持するほどもう余力はない。
Re: (スコア:0)
平和主義とか9条とか…
Re: (スコア:0)
彼らはあれが飯のタネですよ？
西暦和暦変換 (スコア:1)
＃もう離脱したのでID
寝言かな？ (スコア:0)
CIOは首を切られて当然じゃないスカね。
今まで無駄なシステム回収費用を垂れ流して、潰れないし首切られないし。天国ですね。
改修しなければ金はかからないのか (スコア:0)
・April 2018 Updateで「？？」が出ないか(もちろんDBに紛れ込まないことも)検証する必要がある
・April 2018 Updateで2019年以降の平成入力がエラーにならないか検証する必要がある
・来年の5月ごろにはバージョン1709はサポート切れだから、バージョンアップしないという選択肢はない
・一方Windows 7/8.1やLTSCのサポートは続いているから、レジストリに新元号の情報が入っていない環境も要検証
書類や証明書などは元号での表記を継続する。 (スコア:0)
https://www.jiji.com/jc/article?k=2018052100883&g=pol [jiji.com]
阿呆が
Re: (スコア:0)
これはたいへん現実的な妥協案だと思いますよ。
帳票で「平成」を使い続けるいいわけをもらえたんですから。
システムが稼働したばかりのところとか、仕様変更でいくらかかるかわからないし。
Re: (スコア:0)
なんで元号を嫌がるだけで日本人じゃないんですかね
そもそも日本人じゃなくて問題でも？
元コメだが「元号を嫌」とすら言ってないよ
文化としては理解できるし尊重する人がいるのも否定しない
ただビジネスで使い続けるのが合理的とは思えない、改めるいい機会だろうに
確かに「阿呆が」は誤解を招くかな、その点は悪かった
Re:書類や証明書などは元号での表記を継続する。 (スコア:1)
合理的というだけで切り捨てる時点で
自国文化を軽んじてるという事なんだけどね
徐々に意識させなくして最終的にそういうものがなかったように仕向けるのが
文化破壊のやり口なので、そういう点でも反対なのです
逆に文化って無意識の中に入ってるものだから
書類上でも残すのが大事
※あって当たり前、というのがいい状態
PS:システム的に面倒くさいから「阿呆が」という発言なら理解できたのですが、
表示だけだとそれほど面倒くさい想像が付かなかったのでああいうコメントになりました
・・・面倒くさくないよね？
Re:書類や証明書などは元号での表記を継続する。 (スコア:1)
元コメだが丁寧なレスをありがとう
文化ってのは暮らしの中の余裕とか余興で、それがあるのは幸せですが
どこまでやるかは現実の利益・不利益との兼ね合いかと
たぶん、振り回され疲弊するようでは本末転倒
文化を守るためなら、非日本人扱いも辞さない (スコア:0)
関係ない話ですが、文化を守るという立場では、
システムの改修が間に合わないという理由で、改元後も昔の元号を使い続けるのは
「合理的？(システム改修のために人・金をつっこまなかった)な理由だけで」改元後の元号をないがしろにする
ことにはならないのでしょうか？
もしそうでないなら、例えば、向こう70年近く平成を使い続けることは可能なのでしょうか？
# システムで簡単に扱うことができるのであれば、
# 和暦⇔西暦の変換はシステムが苦しめば良くて、人が苦しむ必要はないと思う。
# 内部的に西暦で持って、入力・出力時に和暦変換するなら、
# ・表示の際は西暦を表記
# ・入力は和暦か西暦か選択可能
# とすれば、西暦に慣れている人にも、和暦に慣れている人にも優しい作りだと思うのだけれども
Re: (スコア:0)
昔、お寺さんのシステム開発したときに、
「元号は神道ですんで仏教は西暦を使います」と言われたことがある。
＃なお全ての宗派がそうかどうかは定かではない。
Re:書類や証明書などは元号での表記を継続する。 (スコア:1)
「元号は神道」ってそのお坊さんも宗派か宗教の括りに相当拘りがありそう。
薄々なうろ覚えですが、確か般若心経だったかで「こだわりを捨てればいいよ」とか言ってた気がする。
今度は (スコア:0)
2038年問題引き起こすに一票
コンピュータが対応していてもバイナリ形式で時刻データ保存したりやり取りすると、仕様が残念(符号つき32bit)だと桁溢れ起こす
Re: (スコア:0)
2038年問題引き起こすに一票
にれみや無問題ということで大丈夫だ問題ない
Re:それは屈辱的だ (スコア:1)
ISO教に改宗しましょう。