パスワードを忘れた? アカウント作成
13603825 story
日本

中央省庁の行政システム、日付の記録に西暦を使用する方針へ 99

ストーリー by hylom
DBのテーブルはどうなっているのだろう 部門より

政府が各省庁で使っている行政システムでは、現在西暦と元号のデータが混在しているそうだ。しかし、この元号で管理するシステムでは改元の際の改修コストが高いという問題があった。そのため、今後各省庁の行政システムにおいては原則として日付データを西暦で管理する方針にするという(読売新聞時事通信)。

こういった動きは中央省庁だけでなく、地方や民間企業でも進んでいる。たとえばJR東日本は昨年12月から3月にかけて切符に印刷する発券日を西暦に切り替えている。さらに首都圏の私鉄各社も切り替えを行っているという。

また、京都府内では転入・転出届などで日付を西暦で記入できる様式が広まっているという(京都新聞)。佐賀県でも本年度から公文書の一部で西暦を併記しているというが、和暦を完全に廃止するという動きはないようだ(佐賀新聞)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年05月22日 18時50分 (#3412788)

    君たちが公表をギリギリまで引き伸ばすため全力を尽くしてくれたおかげで西暦移行の大義名分が立ったよ
    新元号に移行しないのであれば、西暦移行まで平成を使い続ける [it.srad.jp]のもまあアリだな。

  • by honttt (48326) on 2018年05月22日 17時46分 (#3412752) 日記

    今は2012は24年だったなで計算してる
    12が24で覚えやすかったから

    • by honttt (48326) on 2018年05月22日 18時45分 (#3412785) 日記

      発想としては12時は24時

      親コメント
    • by Anonymous Coward on 2018年05月22日 19時09分 (#3412806)

      1ダース追加で良くない?

      親コメント
      • by Anonymous Coward

        確かダースだから・・・カーネル3ダースで36足せばいいのか、と勘違いしそうだ

        • by Anonymous Coward

          確かダースだから・・・カーネル3ダースで36足せばいいのか、と勘違いしそうだ

          カーネルダンプで12取れましたので残り24です

    • by Anonymous Coward

      1988(平成0年に相当)の方が覚えやすくない?
      8だけ覚えとけば、あとの数字は簡単に補完できるし

    • by Anonymous Coward
      つことは18年は36年なの?
    • by Anonymous Coward

      今後は2012は12年に変換するから楽勝だなっ

    • by Anonymous Coward

      昔、そろばんやってた時に、8月8日がパチパチでそろばんの日と設定されていて
      西暦から88引いた下2桁が平成の年だと習ったわ。

      2018 - 88 = 1930 → 30年

  • 本当に西暦で持つの? (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2018年05月22日 18時19分 (#3412769)

    どのレイヤで「西暦に統一したる!」と言ってるのかよく分かんないけど
    DBでの話なら、西暦とかじゃなくて、dateとかtimestampの方が素直じゃねと思うが。。。

    いやまぁあるよね。DBでも西暦年月日8文字の文字列で持ってたり、数値で持ってたりする所も。
    これはこれで、なるほど、DBの中身を覗きやすい・テストしやすい・日付の設定ミスを見つけやすい、とは思った。
    検索やソートの速度もわりと問題無かったし。
    でもグチャグチャなソースコード追ってると、この関数の引数は年月日8桁を想定してるのか、それとも
    時分秒まで加えた14桁を想定してるのか混乱してて、そこで妙なバグを出してたりもしてた。

    • by Anonymous Coward

      決定権持ってる人がデータ形式なんて理解できるわけないじゃない
      手書き紙ベースで出来るのになんでできないんだとしか思ってないよ
      下は上に具申する権限すらないので朝令暮改もありうる

      • by Anonymous Coward

        キャリア官僚系は課長補佐クラス(30代くらい)が事実上の決定権を持っていて
        課長より上は決裁権はあるけれどほとんどのことについては
        事実上ハンコ押すマシンだ、と聞いたことがあるけれど

        • by Anonymous Coward on 2018年05月22日 18時47分 (#3412786)
          IT系だって事実上の実装してるのは下請PGクラス(30代くらい)で
          元請SEより上はエクセルに線を引くマシーンじゃないの
          # なお両者とも決定権はない
          親コメント
          • by Anonymous Coward

            決定権を持つのは顧客です!

            #なお客先担当者に決定権はない

    • by Anonymous Coward

      そんなソースだったら日付型を採用しててもdate型とtimestamp型の比較でバグを出してるでしょうよ。あとタイムゾーンが人類には難しすぎる。サマータイムとか絶対無理。

    • by Anonymous Coward

      手書きの内容をそのまま保存()が原因
      →文字列保存。
      だから日付として解釈不可の値が普通に入ってる。「弐拾壱日」みたいなのはマシな方。
      さらに打ち間違い言うか見た目だけで「ニ」
      (半角カナの「に」)を2として入れてたり。

      だが処理時には正しい日付としてちゃんと処理しろ()なんだよね。

    • by Anonymous Coward

      通達

      開示請求で公開しない文書は13月以降の月日とする

    • by Anonymous Coward

      DBのDATEとかTIMESTAMPにするとな、時刻までもってるからって日付の処理を日時で処理する派遣PGがいるんだよ。
      若しくはSYSDATEとかで現在時刻を突っ込むDB管理者がな、いるんだよ。

      もっとも、文字列や数値にしたところで、こんな奴らは何かとやらかしてくれるのでフールプルーフにはならんのだけど・・・
      そういや月の加減処理が正しく出来ないなんて低レベルなことしてくれた奴も前世紀にみたっけ。

      特別な理由がなければ普通は素直に日付型使っとけと思いますけどね。

  • 省庁がデータを西暦に一本化するというのは、記事を読む限り、内部での記録形式のことのようですね(今まで、省庁によっては元号方式での記録をしていたという事も驚きですが)。

    一方、切符の印刷の話は、タレコミ文章やググった記事 [jiji.com]を読む限りでは、(記録データが西暦かどうか不明だが)少なくとも表示は西暦にすると読める。

    • by Anonymous Coward

      元号で持つと二千年問題がないんですよ。どやぁ!

      というか、二千年問題対応時分に聞いた話だと、あれは二桁で持ってた故の問題だったわけですし、
      汎用機時代からCOBOLで連綿と処理してきたデータだとそんなもんじゃないんですかね。
      他に皇紀でもってるから大丈夫みたいな話も聞いたことあるし、データストアもRDBとは限らんわけだし。

      • by Anonymous Coward

        皇紀ってまだ使ってるんですか?
        神社なんかには皇紀~年って書いてあった気がするけど。

  • by cosmosky (47512) on 2018年05月22日 18時30分 (#3412779) 日記

    廃止しない方針なら、元号を「そんなもんあったねえ」くらいのものにしてしまいましょう。
    学校では日本史の年号も西暦で覚えるし。

    • こういう考えが普通に出てくるのが
      戦後教育の賜物だな

      自国文化を軽んじるのは若さゆえか、
      それとも単に自国民じゃないだけか

      • by Anonymous Coward

        別に元号は文化でもなんでもないと思うんだが。

      • by Anonymous Coward

        どうせ元号なんて中国かどこかが発祥の文化だし。

      • by Anonymous Coward

        尺貫法を捨てたときも「売国奴」「文化を大切にスべき」論者が湧いてきたと推測する

      • by Anonymous Coward

        腹がふくれるふくれないで判断すりゃええのよ。
        銭にならない文化()なんて保持するほどもう余力はない。

        • by Anonymous Coward

          平和主義とか9条とか…

          • by Anonymous Coward

            彼らはあれが飯のタネですよ?

  • by krishna (10333) on 2018年05月22日 18時56分 (#3412795) 日記
    前の現場では生年月日を入力するのに西暦・和暦(大正、昭和、平成)ってボタンで選ばせて、内部的には西暦で処理するんだけど、クライアントが和暦を選んでたら画面には和暦で表示していたので、あのあたりどうするんだろうなあって思ってた。
    #もう離脱したのでID
  • by Anonymous Coward on 2018年05月22日 18時24分 (#3412774)

    CIOは首を切られて当然じゃないスカね。
    今まで無駄なシステム回収費用を垂れ流して、潰れないし首切られないし。天国ですね。

  • by Anonymous Coward on 2018年05月22日 18時59分 (#3412796)

    ・April 2018 Updateで「??」が出ないか(もちろんDBに紛れ込まないことも)検証する必要がある
    ・April 2018 Updateで2019年以降の平成入力がエラーにならないか検証する必要がある
    ・来年の5月ごろにはバージョン1709はサポート切れだから、バージョンアップしないという選択肢はない
    ・一方Windows 7/8.1やLTSCのサポートは続いているから、レジストリに新元号の情報が入っていない環境も要検証

    • by Anonymous Coward

      これはたいへん現実的な妥協案だと思いますよ。
      帳票で「平成」を使い続けるいいわけをもらえたんですから。
      システムが稼働したばかりのところとか、仕様変更でいくらかかるかわからないし。

  • by Anonymous Coward on 2018年05月22日 20時48分 (#3412866)

    2038年問題引き起こすに一票

    コンピュータが対応していてもバイナリ形式で時刻データ保存したりやり取りすると、仕様が残念(符号つき32bit)だと桁溢れ起こす

    • by Anonymous Coward

      2038年問題引き起こすに一票

      にれみや無問題ということで大丈夫だ問題ない

typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...