【プログラム/和暦】簡単だと誤解されがちな、システムの「新元号」対応
■ このスレッドは過去ログ倉庫に格納されています
【日高彰の業界を斬る・13】 新元号の発表は、2019年5月1日の改元の半年前と言われていた時期もあったが、新聞報道によると、政府会合では改元1カ月前に発表する方針で固まったようだ。
改元に関して合わせて話題に上るのが、情報システムの改修だ。民間企業の日常業務では西暦を使うことが多いが、官公庁、金融機関、公的機関に提出する文書等では、まだまだ和暦が使われており、日々の業務で使われているシステムが新元号に正しく対応できるかは、業種を問わずあらゆる組織における関心事になっている。
「そんなこと今から簡単に準備できるじゃないか。とりあえず“？？”とでも表示されるようにしておいて、新元号が発表されたらそこだけ書き換えればいいのでは」
このように思う人は多いだろう。筆者もまさにそう考えていた。しかし、長年にわたって使い続けられているプログラムに手を入れるとなると、そう簡単な話ではないらしい。
マイクロソフトは、新元号対応に関する情報をまとめたサイト「Japan New Era Name Support Blog」で、「合字」の問題を指摘している。合字とは、例えば「平成」という複数の文字を、1字分の文字で記号のように表現したものだ。これは元号のほか、単位や法人格でもよくみられる。
同社によると、和暦の表示にこのような合字を使用しているシステムが「相当数存在」するという。国際的な文字コード標準化団体のUnicodeコンソーシアムでは、日本の新元号のためにコード位置を確保するようすでに提案が行われており、コード「U+32FF」が割り当てられる見込みだ。
当然のことながら、新元号の発表後にフォントのアップデートが行われるまで、U+32FFは字体が存在しない“空き地”だ。フォントを更新した環境では新元号が表示されるが、それ以外の環境では空白や他の記号などになってしまうだろう。個人や限られた範囲で利用する文書ならともかく、役所や銀行が発行した書類の日付が「〓01年05月01日」というわけにはいかない。各端末のフォントのアップデートとテストだけでも、トータルの作業量はそれなりのものになりそうだ。
単に表示や印刷ができないだけではない。明治から平成までの合字はコード位置が連続していたが、その前後にはすでに別の文字が割り当て済みなので、新元号は飛び地に割り当てられている。西暦から和暦合字に変換する処理の中で、合字のコードが連番であることを前提にしたプログラムが書かれていた場合、複雑な改修が必要になる。複数のデータを日付順に並べ替える、新元号を含むデータを検索するといった処理も、正しく動作しない可能性がある。
また、元々のデータが和暦で作成されていると、対応はさらにやっかいだ。日付を西暦でなく和暦で管理しているシステムが今どき存在するのか疑問だったが、朝日新聞の5月18日報道によれば、政府は「システム間のやり取りを西暦で統一するよう、関係省庁に中長期的な改修も指示した」といい、現在でも一部でシステム連携に和暦が使われているようだ。（古いプログラムでは現在もまれに昭和2ケタで日付を管理しており、3ケタにあふれる2025年の誤作動が懸念される「昭和100年問題」もあるという）
手書きの書類をスキャンして、文字認識によってデータを入力するような業務でも、認識エンジンの新元号へのチューニングが1カ月で行えるかはわからない。そのほか、新元号が3文字以上になったり、ローマ字表記の頭文字がこれまで略称として使われてきたM・T・S・Hと重複したりするかもしれない。
ここまで挙げたすべての問題は「あくまで可能性がある」水準のものだが、業務に使うシステムである以上、きちんとテストする必要がある。改修作業そのものよりも、検証により多くの手間と時間を要するケースも多いだろう。また、国内では大企業も含めほとんどの組織が、情報システムの保守・運用を外部のITベンダーに委託している。仮に1件ごとの改修・検証は短時間で済むとしても、来年4月はベンダーに改修依頼が集中するため、案件をさばききれなくなるおそれはある。
「そもそも改元を想定していないシステムが悪い」「和暦でデータを入力するユーザーが悪い」といった意見はもっともだが、そのようなシステムやデータが現実に存在する以上、何とか対応しなければならない。エンドユーザーとしては専門家にまかせるしかないわけだが、単に設定ファイルに1行書き加えれば済むというものではないことは知っておく必要があるだろう。（BCN・日高 彰）
5/20(日) 12:00
BCN
https://headlines.yahoo.co.jp/hl?a=20180520-00000001-bcn-sci プロパティファイル用意しておいて、そこから参照すればいいだけ
ソースコードもgrepすれば全部見つかる そもそも平成の文字をソースコードに直接書き込んでるシステムなんてないだろ 昭和→平成の頃と違って、今はネット時代で西暦がスタンダードだしな。
和暦はあってもいいが、公文書やビジネスは全て西暦で統一でいいと思う。 >>4
２０数年前に俺が作った某企業用プログラムでは直接書き込んだぜｗｗｗｗｗ
まぁ今使っているとは思えないけど 安倍元年
＝＝＝
| .|
┌┴┴┐
￣|￣ .Ξ|￣
|尊..Ξ|
|皇..Ξ| ﾌﾟｽｯ
| ..Ξ| ；・ ▀ ▪ ▂▄▅▆▇■▀▀〓◣▬ ▪ ￭ … ．
￣|_|￣ ：;; ；￭ ◥◣ ◢▇█▀ ¨▂▄▅▆▇██■■〓◥◣
. / 、o ヽ / || /::"・∴▂▅██▅▆▇██▀▀ ◥◣
/ | ＿_ノ ・ .,. | .、▂▅▇███ …．▅ ￭ ◥◣
.,.■■■■■・：;;；・ ▪ ￭ ∴‥ ∵▃ ▪ ・
■ ジャップ■ ▪ ∴ …．
ii. ￣" "￣ii
／ヾ｜ ( ﾟ) (ﾟ ) |
／／;;>〈 ___ ｜｜.__ 〉 天皇陛下バンザァァァァァァイ！！
／／γ ｜ ●● ｜
ｿ_ｿ>'´.-!、 ＼ Д ／
τソ －! ヾ ｰ-‐ ｨ､..
ﾉ 二!__―.' .-'' ＼
/＼ ／ つまり元々改号を意識せずに設計した
アホSEが悪いということですな
自分で不具合埋め込んで
その改修費用請求するとか
ヤクザでもやらんぞ？ いい機会なんだから和暦を使うのやめりゃいいんだよ
今やめなかったらまた何十年かすると同じ面倒臭い思いをしなきゃいかんのに 昭和→平成や2000年問題の時点でアホなプログラムなくなってるやろ 国体に関わることだから安易に西暦にすればとは言いづらい。
これはそこにつけこんでもっと金出せやという意味の記事。
改修が難しいのは設計時の問題だろと思う。 そういや車検のシール、今のは平成30年て書いてるけど次更新したら31年とか32年とか書いてあるの？ 元号対応できてないシステムなんて欠陥のバグなのに
頭の悪いシステムのほうが改修作業で儲けて実績が上がるんだよね。 >>1
少しはまとめる努力をしろよな
これじゃタダのコピペ猿だぞ >>20
こんなボロい商売滅多にないぜ
その割に下っ端は地獄だけど
だれが儲けてるのかなこの業界 >>18
西暦でいいだろ
ガラパゴス化はもうたくさんだ 元号ってもう日本しか使ってないんだろ
貴重なものだから続けた方がいいわ
世界遺産になるわ やっぱチョンが「もう和暦やめろ」と連呼するスレになってんの？ 何も知らないアホに記事を書かせるなよ
> 新元号が3文字以上になったり、ローマ字表記の頭文字がこれまで略称として使われてきたM・T・S・Hと重複したり
って事がないのが前提だと、散々報道もされてるだろ >>19
俺の免許証は平成34年まで有効って書いてある 昭和から平成に変わるときにその場しのぎの対応をしたツケかもな。
昭和の年の値が65以上だったら63を引いて年号には「平成」と表示、みたいな。
そのうち直そうと思ってるうちに直した人は退職、
残った人は普段の使用で困らないからそのまんま放置。
まぁ実際のところ、100年に3回くらいしか起こらない改元を見越して
プログラムを組んどくのが利口かどうか分からん。
次の改元までに「書類の年号の使用は廃止、すべて西暦で表記」と
制度が変わる可能性だってゼロではないわけだし。 >>19
そだよ まだ正式決定じゃないし
正式文章には和暦を用いなければいけないという決まりがある >>1
尺貫法からメートル法に変更したのと同じ手順をとれば、西暦に変更できるのだろうか >>2
まともな開発者なら2000年問題や平成になったときに内部処理は西暦に切り替えているだろう
入力や出力の時に必要なら変換して入出力するようにしているから、手直しはその変換ルーチンだけ
年号の合字なんかも普通は使わない。二文字で出力する。 設計時にはキッチリ対応していても、想定外の運用をやられるから困る
改元時には一斉に変更するハズだったのにこことここは平成のまま残すみたいな >>1
元号を変更することが上流工程で、
元号の変更に対応することが下流工程になるのだろうか >>3
ひたすら「安倍憎し」のネトエラ（ネット工作の在日朝鮮人）がすごい勢いで暴れまくってるからな。
日本に密入国してきて図々しく居つき、
生活保護を受給しながら性犯罪を繰り返し
日本人になりすましネット工作を続ける在日朝鮮人。
在日朝鮮人はスパイそのもの。
帰化人を含めて朝鮮人全員をいったん強制送還するしかない。
●●● ネトウヨ連呼厨（ネトエラ）の正体 ●●●
http://karutosouka2.tripod.com/uyokusyoutai.htm
. >>32
確かに、そんなこと書く奴に改元を語る資格わないわな。 実は、柔軟に和暦入力でも西暦入力でも処理できる関数なんかが地味にヤバイ。
関数(2018)=2018
関数(30)=2018
こんな感じで処理するプログラム、社内リソース限定だと地味に沢山存在するのよ。特に総務や会計業務で。 なんとかして元号無くそうと必死だな
西暦をなくせよ日本には皇紀がある
西暦を世界基準にするな。宗教戦争の一因となる SEが、悪いとか言ってる奴いるけど客が和暦使えとか要求してるからそうなるわけで。 >>26
汎用機ならともかくPCサーバやC/Sなら
「Microsoftの対応がわからないとなんもできません」で
いいからな。ある意味楽。 1989年は和暦で何年かというクイズはちょっとだけ難しいぞ。 >>46
役所の仕組みにも大量にありますよ。
そうやって誤記してくる申請書を受け付けるためです。 共産党 「元号制度やめた方がいい」 政教分離の原則に反する
https://asahi.5ch.net/test/read.cgi/newsplus/1521947059/
じゃあキリスト由来の西暦もやめた方がいいな
あと日曜、土曜休日もやめるべきだ。キリスト教やユダヤ教由来だから >>1
Java 1.4 とかで動いてるシステムで和暦を Calender class から取得してたりすると
Calender class の機能拡張を誰がやってくれるのか揉めそう
Java 8.0 以上しかサポートしませんとか言われたら
サーバー更改並みの金が掛かるな 「１年」を「元年」と表示させるのも地味に面倒くさい 大変なのに自民党に配慮して一ヶ月前に発表っていうのがなあ ひたすらWebサイトのプルダウンに新しい元号を追加するだけの
簡単なお仕事です >>2
行政は西暦に統一するとか朝刊に出てたぞ
見出ししか見てないから詳しくは知らん 昔、新人がうるう年は4年ごとと勘違いしてプログラム組んで2000年に大変なことになったことある 日付計算自体はまともなプログラムならシステム日付でやってるだろ 新聞やら官報の関係で外字が来ることは無いんだから
わざわざ勧告に従って専用領域使わんでも良いだろ もう和暦も日本語もやめようぜ！
２つの元号を使い分けたりたかが言語なのに２つも覚える意味がない
俺は我慢して両方やるけどせめて子供たちにはそれをやらせるのは
やめようぜ 2000年問題の時に
基本の日付は西暦に直してるだろ
逆に今時、和暦で動くプログラムとかあるの？ >>53
それは数学の問題と一緒で場合分けするんだよ >>69
お役所系基幹とか全くそのままだし帳票とかレイアウト調整絶望的だぞ
あと恐ろしいのは改修に改修重ねて普段は疎通してるだけで機能としては意味なくて一見デッドコードなのに
こういう拡張するときに我先にと落ちていく隠れモジュールとかあったりな
馬鹿馬鹿しいしどこかのタイミングで捨てて移行しておくべきだけど、リスク込みで対応しようとしたらその予算もつかないシステムが公共まわりは結構ある 皇室とお公家さんで私的にやってる儀式にしとけ これこそ国体護持だ
政治が介入しないように一般社団法人朝廷とかにして
一流の国学者と漢学者集めて勝手にやっててほしい >>1
なんつうか。無理矢理、ちゃぶ台を広げた炎上商法だな
1.合字がー → 文字コードの問題。改元なくても存在する問題
2.和暦データーがー → 内部処理は西暦が基本。なんなら皇紀でもよし。元号マスタは初歩
3.OCRの機械認識精度ガー！
→日常だろ。そんなん。 記事を書いてる人がプログラミングを実際は全く知らないのに
知ってるっぽく書いてるだけのような気がするが >>16
要らないね
今時システムにこんなの残してる時点でセンスのかけらも無い奴だとわかる >>35
あの時はその場しのぎをするしかなかったと思う。
ただ今回は根本的に見直す時間があるんだからきちんと対応しないとね。 あと恐ろしいのは、表記の変更さえ誰も決断してくれない
役所の場合、既存から変える決断が些細なことでもハードル高い
帳票が㍼㍻表記だったらそれをS Hに変えるとか西暦に変えるとか誰も決断してくれないから「そのままで」となる 平成に変わる時点で普通のSEなら対応済みなんだよ
そして変な文字も使わない >>65
笑う
これやったら、対応してるのが当たり前だろガス！
といっとるやつらも次々と撃墜するだろうな
神武天皇即位紀元 2678年とか。 >>9
契約の上では保守期限は5、6年なので特に問題は無い。 キリスト教はウサンクサイが天皇なんかもっと胡散臭いだろ(笑) 和暦対応ってめんどう金かかるわりに生産に寄与しない無駄だよ。
惰性で使ってるんだもん 次の天皇が2～3年かそこらで崩御とかしたら厄介なんだよなぁ >>85
そりゃな。こうきなんかは、疑問符がある。
学説での紀元前600年の日本は、史料がないから研究不足もあるが、縄文時代になるからね 明治 → 戦争の時代
大正 → ロマンのイメージ(ここも戦時期)
昭和 → 敗戦と成長と没落
平成 → 弱肉強食の共食い経済時代
こんなのがおれの時代感ね 画面表示するときだけ切り替えればいいだろ
中の処理は全部西暦だ。 実際やるとしたら新元号に対応するライブラリはまだないから、自力で実装するしかないな 改修箇所の洗いだしと改修時の影響範囲の洗いだし
そして改修後のテスト範囲の洗いだしとやらなきゃならん量は膨大
設計、開発に携わった人員が居るとも限らないし どんだけコストかかってんだか。
日本の労働生産性が悪いのって、こういうつまらん不合理の積み重ねなんじゃねえの？ 簡単だと思い込んでる旧時代のポンコツを駆除することが肝要
和暦対応が大変であることを理解して、改修の時間を確保するためにさっさと新しい元号を公表すればよい
盛り上げるためにぎりぎりまで公表しないとか言っている政治家は全員クビにしなさい
なぜならそいつは時代遅れの欠陥品だからだ ド素人でも、内部的には西暦にすれば良くね？と思ったんだが >>24
Windows3.0どころか
Dosvだった マイクロソフトは日本が金をだせばやると言ってくれ。10兆円で。 >>99
そうした国民の想いを受けて内閣府の心ある人が覚悟の元号半年前リーク、非公式ながら業界は一安心、からの～、リークに激怒の安倍ちゃんが非情にも別元号を一ヶ月前に発表して業界阿鼻叫喚とか見たいw >>105
ソレ和暦使えってなってないから西暦で書いてもok 西暦に統一するついでに「年度」とかいう中世みたいな仕組みも辞めちまえ。
元号はまだいい、日本の伝統として残してもいい。だが、年度、てめえだけはだめだ。 入会申し込み画面で、生年月日入れてもらうのに西暦と和暦と用意するしな
結構面倒。内部では西暦管理するから、変換したり、変換したのを戻したり 俺んとこで面倒いのはプレ印刷の枠に丸や塗り潰しやレ点を印刷する位置合わせ
選択肢の元号が増えると明治ー平成の位置もズレるんで、印刷、位置修正、印刷、位置修正をひたすら繰り返す
しかも元号発表して印刷出来てからしか作業出来ねぇ >>113
入力時の選択で昭和と平成があってしかも格納時に西暦変換してるタイプなら、マスタ(プログラム内にハードコーディングも含め)に新元号追加するだけじゃね？ >役所や銀行が発行した書類の日付が「〓01年05月01日」というわけにはいかない。
01年の場合は「〓元年05月01日」にしてくれとか
02年～09年は「〓２年05月01日」のように全角にしてくれとか
言われる現場の声を拾えていない 日にちだって、今日は５月２１日だけど、
ユリウス通日だと2458260日だぞｗ
つまり通年や通日は実用に耐えないんだよ
どこかでリセットさせて進行していく必要がある
つまり元号は正義 >>116
元年はともかく、全角と半角の数字が混ざるのはものすごく気持ち悪い >>116
そもそも元号は2文字って決まりを知らないアホが書いてるからしゃーない >>116
平成元年は1月だけは昭和64年にしてくれというところもある 元号だけ決めて、年月日には使用しないようにしてくれりゃいいのにな
2018年は平成だけれど、平成何年とは呼ばない
年表を見て何天皇の時代だったってわかればいいんだろこんなん はじめから西暦だったら起きない問題
西暦の場合U+0030～U+0039の文字4桁がオーソドックスだし 昔使っていたパソコンソフトは、半角漢字が打ち出せたな、MS-DOSの時代だけど。 いつまで非効率な和暦引きずるんだ
IT後進国から抜け出せないだろ >>1
お前システムやってないだろ
こんなの問題になるかよ
アホ >>124
今時打ち出すプリンターって請求書用くらいしかなくない？ さらにめんどくさいのが元号をぎりぎりまで秘密にしてる事だろ
切り替えはきっちり準備しておけばいいかもしれないけど
その後のテストはどうあっても時間がかかる >>126
システムをそう作った役人に罰を与える必要があるってこと。 俺の職場の業務ソフトは自社開発だから楽だわ
新元号が決まったらアップデートボタンを押して定義ファイルを読み込ませるだけ >>131
1か月でオケって進言したバカを晒してほしい >>104
日本ではPC-98だった
MS-DOSどころかN88-日本語BASIC（86）もあったしな 兆円単位の損失だよね
書類もシステムも全部変更が必要
ほんといい加減にしろよ 人間はこういう計算て大変なんだよ
でもコンピュータは電子計算機というだけあって
こういうのこそお任せあれなんだよ
なんなら皇紀も併記できるし
マヤ歴でもいいぞ
こんなんで元号を毀損することはできんぞ >>130
請求書や袋綴じの給与明細くらいだな
>>35
生年月日を扱うシステムは少なくとも明治、大正の元号変換が必要だからこんなトラブルは起きない はず 日本はソフト開発弱いっていうのは
英語が苦手なのと元号も影響してたんかなぁ 今時和暦なんて使わないだろ
と思ったけど役所と銀行は多そうだな
ご愁傷様 >>127
この程度の変換さえできなくて「IT先進国」とやらになれるのか？ >>103
今のシステムは内部的には西暦が普通だと思うぞ
特に今回は崩御ではないから、元号は公表されていないが具体的にいつから新元号かは
公表されてるんで、プロパティファイルにダミーを打ち込んでおけば解決
今上天皇のおかげで、少なくとも我が社のクライアントは安泰です 2000年以降に内部処理で和暦使ってるのって頭悪いか手抜きかのどっちかだと思う >>141
まてよ
年の表示されてる帳票20のうち19が和暦
これが役所！ しばらく併用可で良いんじゃー？
でもクレームつけるバカが、一定数いるからな。 個人的に自衛隊のシステムがどうなってるか不安やわ
これが一番重要だし
その次が医療
国防にまで影響あることを認識したほうがいい 和暦の改元ごときでピービーいうな。
それこそIT後進国だろ これほんと邪魔くせーよなｗｗｗｗ
糞の役にもたたんし
西暦なら金はかからんのに 前のシステムの無駄なものまで引き継ぎたがるから一度付けたら削除するのは難しい そもそも2000年くらいにシステム改修してるはずで
その時に元号が変わる想定をせずに設計してる時点で程度が低いだろ 合字なんて使う？
ハゲのおっさんがwordで使用してるだけのイメージだが・・・ >>159
1980年ぐらいから見た2000年ってそんな感じだったんだろうな
きっと未来のスーパー技術がなんとかしてくれる！って よくわからんが、勝手に隠居した天皇さんが悪いってことでいいのかな？
つか、１年目はやっぱり○○元年って表示しなきゃ怒られるよなあ >>162
従来の崩御で変更の方がもっと混乱するぞ 以前いた自治体の旧システムは
日付も和暦で登録してたな。
昭和は頭3，平成なら頭4で。
全国パッケージ版を導入してるとこは問題ないと思うがね アホなプログラマは外部参照にする
デキるSEはハードコーディングする 改元に対応してないマヌケなプログラムの問題だろ
和暦の良し悪しの話じゃな >>165
半年はワックス不要水洗いだけで驚きのツヤみたいな？ ３０年前に平成に改元された時に、
将来の改元も見越してシステム修正していないのはＳＥとしては最低の部類。 >>166
PC98が壊れると止まる工場とかザラびゃね？ >>170
SE「このシステム30年後はリプレースされるだろ」
SE「30年後俺いねーからｗ」 平成の時に、ちゃんとマスタ化対応してんのに、金も出さず全パターンのテストしろとか言う客がいるんだろうな。
いや、金出してくれんなら、こんな作業はむしろ喜んで人増やしてやるけどさ。 >>162
変えない宮内庁とかが悪い
陛下は変化をもたらしたくて退位なされた
陛下は和暦の廃止をまず望んでおられる >>170
裁量権、決裁権が無ければSEがどんだけ優秀でも変えられないものは変えられない。
現場は皆んな分かっている。
分かっている事と、与えられたコスト内で組めるかどうかは別の話。 将来元号が変わるのはバカでも変わっているのに
対応できないようなシステムを設計しているのがクソなだけだろ 将来の改元を見越して実装してるのは当たり前。
だが、システム全体でその機能をテストしているかどうかは当たり前じゃない。
ありがちなのが、
開発会社A 対応してますよ。設定ファイルAに追加するだけです。
開発会社B 当然対応してます。レジストリに追加するだけです。
開発会社C 対応できてるはずです。プロパティファイルに追加するだけです。
開発会社D そこは別売りのコンポーネント使ってるんで。更新してください。
元請け えーと、ちょっとみなさん、落ち着いてまとめてみようか >>170
内部的には昭和のままのシステムもあるので
そろそろ昭和100年問題 昔は紙とか磁気が記録媒体だったから余計なコードは入れれなかったんだ >>180
西暦ですら二桁で処理したい気持ちに勝てないハードウエア環境だったのはなんとなく知ってる 新卒の俺「元号変わったらどうするんですかこれ」
リーダー「まだ１０年は大丈夫やろ」
会社に答えはないと思った１０年前 旧暦の２０３３年問題というのもあってだなｗ
ローカルな問題だけどｗ >>171
工場止まるレベルはなくとも、センサーが使えません！！とかやってる現場ならまだ沢山あるなw >>162
今回は予めわかるからマシな方だろ
前の爺さんとかはいきなり死なれてカレンダー屋とか大損害だっただろ
ほんとこれ糞の役にもたたんからな >>188
さらにその前は、
んーなんかイマイチ景気良くないから、
みたいなノリで変わってた >>188
その類なら、いきなりの2000円札とかな。もう皆んな忘れてるが。
なぜか頑なにお釣りはからず2000円札を使うラブホがある。
もう2000円札見かけると「ああ、こいつもあのラブホ使ってるのか…」とか思っちゃう。正直そのラブホでしか見ないw チュチェ元年は1912年
金正日が提唱した暦で、金日成が生まれた年1912年を元年としている。
パヨク、これも批判しろよｗ >>194
マジで「次の元号は主体がいい」とか言い出す連中なんだから、余計な知恵つけないであげて マドンナと娘の「わき毛」に注目集まる。セレブに学ぶ、自分の身体を「選択」することの意味
http://jsaet.sminted.com/20180021_2.jpg
Windowsがやっかいだよなバージョンによってレジストリにあったり別の場所にあったり、さらにOfficeは独自に持ってたり 行政が好きな書類に和暦に○をつける様なものは全部作り直しだろ
何が１ヵ月前だよ、本当無能だな >>160
単にメモリのバイト単価と容量の問題だっただけだ。
今は特定の時点からの秒数カウントをベースに計算するから西暦だろうが
和暦だろうが秒数から変換するから関係ない。西暦10000年問題なんて言ってる
奴はいつの時代のプログラムのことを言ってるんだ？ >>160
バックトゥーザフューチャーは1985年ころの映画だけど、2015年の未来が当時する。
自動車が空を飛んでて、テレビ画面に現れるAIで描かれた人物が案内をしている。
AIの部分は当たってるけど、自動車やスケボーが空中を飛ぶ技術はないな。 日本独自の暦を使うのは構わんが通年にしろとは思う。
大和暦とかにして天照大神の西暦240年辺りを大和元年にして、今は大和1778年とかで。 >>117
int型なら全然耐えられるな。
long型ならなお良し。元号より全然まし。 今までの明治(M)・大正(T)・昭和(S)・平成(H)の4つから、新元号(?)を加えた5つにしなくてはいけないから
横幅が全角文字3つ位増やさなくてはね。 30年前はネットに繋がってる会社は少なかった。
筆者もネットに馴染みが無かった。
まそんな事で、和暦西暦の煩わしさには無頓着だったけど、世界が広がった今日
和暦何なの？とめんどくさい。
意味がないめんどくささ。
サッサやめればいいのに。 >>206
前回の要件に、漢字二文字と、MTSと被らないってのがあったと想うよ >>201
空間に展開される立体映像ディスプレイまだー？ﾁﾝﾁﾝ >>132
そんなん言ってもしゃーない
お上にしたがうほかないだろ >>206
三文字の元号ってあったっけ？
四文字の元号があるってのは、聞いたことが有るけどな もうすぐ対応終了します。
発表後一週間以内でテストも出来ます。 >>204
なんの言語か知らんがCだとintやlongに具体的なビット数は既定されていない 来年019年が和暦Ｘ０１・・・・・・・このキリバンじゃない合わせがおぼえずらい。
せめて020年が和暦初年だと 20年＋－と憶えるの簡単だけどさ。
１９だと
最初２０＋－してー1なんてアメリカ人の80％が理かい不能になる。 >>1
この作文のどこがニュースですか？＞ばーど ★ >>216
ビット数が規定されないとしたら、longって何が長いの？ >>212
保守期限と貸し担保とまた違うし
基本要件に改元考えろとなかったら知らんわな >>220
intとビット数が同じか長いのがlong システムが日本で作ってないんだから対応が即できないんだろうって思ってた BLACK RXがちゃんと20世紀ライダーに区分されるわけだな
クウガ以降は21世紀ライダーで問題ない >>4
それがあるんだ…
if else で既知の元号判定した後、未知の元号だとそのまま素通りしてヌルポで落ちるw 原発事故もまさかの日本発だったし
軍事機器の誤作動で核戦争の引き金もまさかの日本からかもwww >>145
UIに和暦があればactionもvalidatorもserviceも和暦を扱うしビジネスロジックだって変換噛ませているが結局のところ扱うわけで
お前が言う内部処理が何を指してるのか知らんが 文字列で「平成20年」と格納する天下無敵のシステム フォント絡みのIT大手には新元号事前に知らされるんじゃないのこれ
特定機密でw >>222
長さが規定されていないのに、長くする必要があるのか？ >>200
日本ではPC-98が主流だったからDOS/Vは不要だった
本格的な普及はコンパックショック以後 元号のみで動かしてるシステムなんて
意図的な時限爆弾かよ、ってレベルだな
アホすぎる
>>215
つくば万博なつかしすぎる
なんか知らんけどグッズが家にあった >>1
喉元通り過ぎると、マスコミがもうすでに18年度とか書いてるからね。
一つの文章で平成と西暦ごちゃ混ぜで連ねてた記事もあった。あのバカやつら。 >>78
㈱や℡、㎝や㌢など元号以外の合字も全否定するのかね？ >>4
25年前のCOBOLで動いてるシステムとか普通にあるからな
某県の30自治体のシステムを一括で受けてる某会社にいたがまだそれだよ
なんせ未だに磁気テープだしな
25年前のスパコンより今のPCの方が多分処理早いだろうに >>2
官公庁やJISのフォーマットが和暦だったから今は中は西暦、出力は和暦だね。
さて、元号が代わり和暦推ししてくる組織がどれだけあるか？ 改元1ヵ月前とか正気の沙汰とは思えない。
よくこんなのでデジタル省とか
話題に出て来るもんだ。
呆れてモノいえんわ。 >>237
検索が面倒になる機種依存文字は捨てていかないと、色々な意味で海外の奴らに遅れを取ることになる。 ㍻
㍼
[][]
フォントが作られて更新されるまで当面こうなるわけだ
んでカレンダー業界は「新しい元号は、xxです」とTV中継を見た瞬間に連絡しまくって張り替え用シールの印刷をフル稼働でスタートさせると
あほくさ めんどくさいからもう神武からか乙巳の変からの皇紀作ればいいじゃん 余裕のない時代になったなあ
いっそのこと地震とか台風とか起きるたびに変えちまおうぜ >>240>>242
日本に一番重要なのは
「改元１ヶ月前とか無理だろ、もう2019年は変えずにずっと平成でいいだろ」
という割り切りだと思うんだよ >>4
使ってるわ
素人が思いつきで作ったような糞システムだから年号に限らずそんなのが多々ある
一回打ち捨てるべきなんだがとりあえず動くからの糞精神で使われ続けてる >>1
簡単に出来るようなシステムにしてるのが殆どだろうけど、それを顧客レベルで出来るようにしてるか Unicodeの組み文字はあくまで互換用で使用が推奨されてるのではないのだが。
元号の組み文字使ってるシステムは今のうちに漢字2字に直しとけよ。 いっそ、もう既存の合字から元号決めればいいんじゃね
㌢とか >>249
シングルであろうが6バイトであろうが闇雲に探し回って、有ったらここぞと使っちまえが許されるのは、
「読めない端末が悪い」扱いができるどこかの掲示板のアスキーアートくらいだよね。 ちなみにMSはShift-JISの新元号合字対応しないのが確定だそうなので
テキストファイルやCSVでデータやりとりしてるシステムで元号の合字使ってるところが思いっきり引っかかる模様 >>241
言いたい事は分かるが、機種依存文字ってローマ数字等もあるからなかなか排除しづらいのが原状だし、
英語圏の「＼（バックスラッシュ）」と日本の「￥（円記号）」が同じ文字コード（半角の場合）
なのは変えようがない。
シフトJISも日本ローカルだから海外に合わせて全てユニコードにしろ、と言うのも無理ゲー。 元号部bんは単なる参考の文字データや
文章を書くだけで変換候補無いなら手動で書き足すだけだけど
あらかじめ元号も決め打ちされているプログラムは面倒 内蔵や決め打ちされてたり年月日の範囲に指定があったりするのは
後で変わる事を考えてない糞システムだけどね・・・だけど結構ある
こういう部分はあらかじめ決まってて選択式でなく後から変えられるようにしとくべきなんだけどね
昔々のものとか性能による制限もあったんだろうけど >>253
長年稼働中のレガシーシステムに「今どき」って言って何か意味あるか？ 混乱がないようにってことで陛下は譲位されるのに
ゴミ政府におかげでｇｄｇｄだわなｗ
新元号は1月1日からにすりゃいいのに
国民の人気取りの為なのか5月1日で連休にしたり
新元号発表は1ヶ月前とかアホの極みだろ オマエラ、和暦を関数とかでやってんの？バカなの？頭悪いのは重罪だよね～。あー、在日白丁どもかwww >>222
えー、uint64_t とか使えよ
もうlongなんて使うなよ
移植性落ちるだろ。 まだ対応してないシステムがあるのに驚き
平成に変わるときアタフタしたから
もう過去に対応・テスト済み >>249
組み文字使ってるのはスペースの関係で小さくしたい帳票用か
「元号のままソートする」とかゆー意味不明な仕様書に従って
アホくさいと思いながら作った外注プログラマのささやかな抵抗だろうな。 >>262
COBOLとかデータベースは数値も文字列で外部とはやり取りするからな
2000年問題が顕在化したのもそれが主な原因 UNIX Timeとか云うの未だ余ってるんだろ甘えるな(´・ω・`) シロウトだと、追加するだけだろ、みたいに思うよ。
何十箇所変えても、人間さまがミスするなんてあり得ないって思うし、
デグレードも含めて、どうやってすべてを確認をすればいいか、
なんて考えてもいないからな。そこがシロウトさんなんだわ。 >>264
ふつうにATMでの通帳の日付や取引伝票の印字にH30とか出てくる。同じ銀行でもATMによって西暦で出てきたり和暦で出てきたりするw 国がISO取得推奨しているのに、国の書面関連では和暦を使うって何やねん。 >>273
○公文書の年表記に関する規則
平成六年三月三十一日
規則第三号
公文書の年の表記については、原則として元号を用いるものとする。ただし、西暦による表記を適当と認める場合は、西暦を併記するものとする。
附 則
この規則は、平成六年四月一日から施行する。
こんな規則まで出来ているからな。 難しいだと連呼しがちな和暦表記、実は小学生でもできるもの >>273
ビジネス面への配慮だろう。一方、欧米はいまだに、インチとかオンス、フィートとかだろう。文化の多様性を尊重すべき >>9
>>15
じゃあ用件定義に書いとけっつー話だろ 別に難しくもないが、個別にキチンと対応しようとすると面倒なんだろうな。
大学とか大手のIT企業がオープンソースで主要言語向けに質の良いパッケージ作って、
ライブラリやテーブルの更新だけで済むようにしとけば、何てことなかった。
簡単だとバカにせずに、実装、運用までしっかり標準化しておかなかったのが失敗だな。 >>279
契約に書いてないから、て
そんなん顔合わせて言う気か？
顔面補整したるわそいつ たとえ何歴で入力しても、enter キーをポンと押せば、瞬時に世界共通の
年月日時分秒の0と１の羅列に変換されるのがコンピュータというものなんだよ。 >>46
そんなの変数化してリストと照らし合わせて処理してるだろ？ >>283
要求仕様に合わせてシステム作るからな
文句は裁判所できこか 世の中には30年近く進化してないオフコンとかあるんやで
作業そのものは簡単なんだよ
ところが、「いついかなるときも誤動作を起こさないか」の確認に時間がかかるだけ
そして、なぜか簡単なことなのに誤動作を起こすようにプログラムを組むバカがいる
時間戻りとかよ(2018年を1918年として処理するなど)
あれは永遠の謎ですわ
>>7
それ多分今でも使われていて
改元後にきちんと動かなくなったとクレームがくる 元号ごときでうろたえるようじゃ
消費税変わったらシステムとまっちゃうんじゃねえのｗｗ >>295
元号は日本語文字混在データだから厄介なんよ
日付だからすべての文書に関係あるし えっと、MSOfficeはどこから対応するの？
2003は無理だよな？ >>2
まずデータ内部表現だけ西暦に変更。
次に申請用紙を再発注するタイミングで西暦による提出も許可するようになるかも。
その後イスラム系国家が世界を征服してイスラム暦に切り替えることになったりするかもしれないw >>1
すべて西暦にしろやヴォケ
融通のきかん能無しは死ね どうせ無能公務員が手作業で処理してんだし
システムが対応しようがしまいが問題ないだろ
あ、無能だから対応できないか、すまんすまん >>299
その時はゲルマンスタンの対応を参考にすればいいんじゃね >>264
全銀の振込入金明細は和暦の年月日
しかも元号がない ちゃんと想定してたプログラムは
ちょこっと書き換えるだけで○百万円の更新料貰えたりするので
ウッハウハのとこもあるはず なんで皇紀でやらないのか理解に苦しむ
要は、改元がない年号でありさえすれば、なんでもいいわけなのだから
皇紀にしときゃ、-660で西暦だし、困ること無いだろ？ >>238
25年前だと昭和→平成の改元を体験してるんだから
次の改元への対策を準備してそうなものだけれども 西暦だってな
俺んとこの会社みたいに社員番号に下２桁しか使ってないとことかあるしな
あ，入社した年のね
「重複する社員は絶対いないから平気」
らしいけど過去の社員と同じ番号とか出たらどうすんのかな
データベースは受け付けてくれんのかな
そういや出身校の学籍番号も西暦の下２桁使ってたな。。。 >>63
うん。それは「100年に1回はうるう年でない」っていう中途半端な情報のせい。
2000年は実際にはうるう年だったのでそれほどそこでの問題は起きてない 皇紀でやりゃいいじゃん
戦前まで当たり前に使ってたんだからそれが一番分かりやすくていいだろ あー、恐れてた事態だよ。
精密機器がバグるわー。
2000年問題より、やばそーだわ まず西暦ってのが正しく言えばキリスト歴なんだよ
一部の宗教に加担するのは政治として宜しくない
ましてや日本は神道と仏教の国
お釈迦様の誕生日からでもいいが、やはり一部の宗教に加担するのは宜しくない
よって日本国として日本古来よりの皇紀が一番いい いや俺ほんまビックリなんだけど
「この手のシステムは決め打ち(定数)が多い」
中学生のプログラムしてんだぜ
ゲームだったら、定数は蛇蝎の如く嫌われており、Cでいうgotoなみに禁止
ところがこれ系、社会インフラなどクリティカルなとこで使われるわりに定数で決め打ちしており
こんなんじゃ止まるわなあって作りもけっこうあるな
さっき住民票取りに行ったら申請用紙の生年月日欄に西暦があって腰抜かした >>318
併記してあるの？
全面移行して欲しいわ 定数だと評価が簡単になるのかもしんね
その値しか来ないと保証されてるしな
だがありゃねえわ
中学生だよホンマ 新元号を発表します
「平成」
え？
「新元号は３１年から始めます」
全員歓喜
「ただし、元号の前に『新しい』を付けてください」
全員死亡 来年の5月以降は平成31年度の何とか元年か？めんどくさいな
>>323
昭和100年問題かかえたシステムもどこかに残ってるんじゃね >>300
もうそんな世の中なんだ。
俺は西暦で生年月日が言えないおじさんだわ。（笑） >>300
アラサーがサバ読むのに西暦で誤魔化すの止めてくれんかね。（笑）
そっちの方が困るわ。 奴ら（官僚）、プログラムを魔法と勘違いしているわ… 最初から年号変更に対応するシステムにしとけばよかっただけ。あほなの？ いい加減役所、民間問わず西暦だけでいいだろ
和暦は伝統文化的な意味合いでだけ残せばいい うちのシステム、イベントに
gyynnnnで番号振ってて平成がg=2なんだが、
・10個め以降の元号の出現
・100年を越える元号の出現
・年間1万件のイベントの発生
には対応できそうもない。生きてる間にはなさそうだが。 >>334
官僚に限らないけどね。クライアントは家を建てた後に「天井高くして！」みたいなことを平気で言ってくる。 一番困るのは、Excelの和暦表示。
おそらく最新版のExcelであるExcel2016や比較的新しい2010～ぐらいは
パッチが出て対応するだろうが、Excel2003とか2007、遡ってExcel97や
Excel5.0などは到底対応するはずがない。
平成改元時はMultiplanと1-2-3が滅んだ。 >>275
政府がいろいろ抑え込みしてて、この前の退位に向けた会見だって、安倍総理を睨んでたよね。 >>315
皇紀はわりと新しい
また西暦に統一も間違い
グレゴリオ歴を引き継いだ、ISO8601で勧告されている表記に統一させるが正しい言い方
元キリスト教歴ではあるが、既に国際標準と決められているし、和暦の入る余地も定められている
また未だに古いユリウス歴を使いグレゴリオ歴を使用していない宗派もいるから一概に「キリスト教歴」とも言えない >>340
日本て何事も仕様変更に対して以上に柔軟だからな（発注者側にとってだけ）
旭川医大の電子カルテ問題とか。 >>85
なら出ていけばいい
または憲法を改正するか
バカなパヨチンはキュージョーキュージョー護憲護憲騒いでいるけと
天皇制度を否定している頭のおかしい連中 >>304
不慮の出来事などで1～2年で次々に改元することに、なったら大混乱だな。 昭和と平成の入れ替えの頃もゴム印かえるだけだったから大したことなかったんだろうけどな 元号の変更ごときでシステム変更なんて設計者がアホか
これを機に儲けようとしている奴だけ。
データを1行追加するだけ。
数分の作業だよ。 >>12
ISO8601で規定されているんだよ
ちなみに月日は明治5年にグレゴリオ歴へ改ためられている
また別に和暦を廃止するわけではない >>348
grepすると吐き気するほどハードコードしてるのが出てくる場合もあってだな。 元号書かないのに年だけ元号の年を利用するシステムは最悪だった 行政やら金融やらの基幹システムなんて昭和のレガシーシステムをツギハギしながら使ってるんだから
今のコーディング技術を基にあーだこーだ言ってる奴は
ひよっ子SEだな >>1
>「そんなこと今から簡単に準備できるじゃないか。とりあえず“？？”とでも表示されるようにしておいて、
>新元号が発表されたらそこだけ書き換えればいいのでは」
いろいろ書いてるけどこれでダメな理由が皆無でﾜﾛﾀ >>352
コボラーがいるから…沖電気の退職者にまで声をかけないと… まともな会社なら昭和→平成のときにそういうの考慮して改修してて
それ以降のシステム更新でもとっくに対応済だから
せいぜいこの程度で済む
・テーブルに新元号文字と略称英字の追加
・テーブルの平成終了日追加と新元号開始日追加
・西暦和暦変換、和暦西暦変換の新元号対応
・必要なら表示や帳票類のレイアウト修正
当然修正もテストも仮の元号で事前にできるから
あとは新元号決まって本番用に修正するだけ
実際問題大した話ではない >>355
昭和→平成が30年前って理解してる？
Windows3.1すら発売されてない頃に改修したシステムが今どんだけ生きてると思ってんだよ 昭和から平成が最近だと思ってるのはゆとりなのか老害なのかが気になるw
物心ついた頃にはネットが普通にあった世代な気はするね >>356
なにいきりたってんのかしらんけど
馬鹿にはこの一文が見えんのか
>それ以降のシステム更新でもとっくに対応済だから そらーゼロから組むならどうにでもなるだろうけど秘伝のスパゲッティソースとかが混ざってくるからな 止めようぜ元号
本家本元の中国でも西暦だけにしてるのに
バカなのニッポン
日本に余計な負担掛けるだけで何のメリットも無い >>341
、Excelの和暦表示なんて簡単だよ。 >>353
表示だけの問題じゃないから
和暦→西暦ができない
日付計算ができない
日付計算ができないから率の計算ができない
など。 >>350
それはある意味いいシステムだ
好き勝手やりすぎてgrepすら難しいことをやらかしていたりとか・・・ >>358
ハァ？バカだろお前
メインフレームのディスク容量30MB時代の遺物をシステム更新して使ってるわけねえだろ
業務継続しててもとっくにリプレースしてるから「元号更新の考慮した改修」なんてカケラも残ってねえよ
本当にバカだな いや、だから、アダプターを適切に作ればそれで解決する話でしょう？ｗ
画像認識とか、そんな所までは面倒みれないよｗ >>367
使ってたりするんだなぁ
基幹系の仕事やったことないんだね >>371
それはどこのどのシステム？
基幹系？銀行の？なんて言語の？知らないよね？
つーかメインフレーム廃止してリプレースしたのにわざわざ昭和→平成の切り替えた当時の対応を今まで残してるシステムってどこにあるの？
＞まともな会社なら昭和→平成のときにそういうの考慮して改修しててそれ以降のシステム更新でもとっくに対応済だから
＞せいぜいこの程度で済む
＞実際問題大した話ではない
「まともな会社」って銀行の基幹システムのみ？
世界のシステムの99%は銀行の基幹システムじゃないけどそれはまともな会社じゃないの？
30年前から連続稼働してるシステムが全体の何%あると思ってんの？それ以外はまともじゃないの？
本当にバカだよなお前 元号をテーブルから取り出して使ってるけど、
元号が3文字というテストで引っ掛かった。
2文字しか想定してないから。
対応してやったから1文字でも100文字でも掛かってこい。(((ง'ω')ڡ≡ コンピュータ処理が平民でもできるようになったのが昭和だったもんだから
平成になる前後は天皇って死ぬんだｗｗｗｗってパニックだった所もあったな 元号は変わるものだ
それを想定してないで作ったシステムが悪い
元号は悪くない この国は「戦前の日本」と「戦後の日本」に分かたれるだろ。
本当は１９４５年を元年として、そこから数える元号を考えたほうがいい。
日本人として生まれて、
この国の真実の歴史をほどほど理解するのに３０歳は越えないといけないわけだ。
若いうちから、この国の自浄力の無さ、弱さを理解するためにも。 >>318
外人さんは帰化しても西暦のまま、戸籍も西暦
住民登録は帰化しなくても良いし >>380
システムを新しくする予算が取れず、そのまま騙し騙し使用され続ける。 >>1
このような問題は、IT先進国の韓国の専門家を呼んで、一度真剣に議論したほうが良い。
韓国ではこのような問題は一切ない。日本は遅れている。 >>363
みずほとかw
(ようやく刷新されるけど) >>375
データ処理的にやれるようにしても、帳票で問題起こるんじゃね >>385
だよな、フォントの問題もあるから印刷してみるまで対応できたかどうかはわからない プログラムより、膨大なテスト結果等の報告資料に多大な工数がかかる時代 中国・ベトナム
「 君主が時間を支配するって。プッ。あいつら中世かよ。」
韓国
「 さすが没落国家は違いますな。へへへ。」
日本・北朝鮮
「・・・。」（プルプル） >>375
新元号の選定基準には、「漢字2文字」というのがあったはず。2文字以上は想定する必要はないと思うよ。
西暦の年数の5桁に対応しないのと同じで。 >>375
元号の漢字の部分は2桁でいいけど、年数の部分は3桁対応が必要かもしれない。 西暦というか神武天皇即位紀元にしては？
西暦2018年は神武天皇即位紀元2678年。 合字自体がunicodeの思想に反するだろ。削除してしまえ。 >>383
ハングルのコード全置換して阿鼻叫喚だったの知らないの？ 昭和から平成に変わった年は消費税導入した年なんだよな。
1月に元号変更して4月に消費税対応。
月の残業時間200時間超えだった記憶。 >>278
メートル法を採用してない欧米の国ってUSだけだが？
さらに科学分野で標準で用いられるSIはメートル法の後継。こればかりは
USの研究者も使う。 20年前にはもうDBでは西暦で
アウトプットの時だけ元号使ってたぞ >>399
メートル法が嫌なら開き直ってFFF単位系にすればいいのに
furlong
firkin
fortnight >>372
本当に知らないんだねー
生保損保は多いよ
ウチも昭和のシステム動いてるし
言語？ もちろんCOBOLだろw
未だにCOBOL replace案件は至る所にあるよ
SOMPOホールディングスあたりは今、人材集めて回ってるしな 1/7までは昭和64年で1/8から平成元(1)年とか、置換するにもそこそこややこしいことしなきゃだよね
親元号対応も言うほど簡単じゃないよな >>403
地方銀行大手3社、自動車中堅2社、銀行系クレジットカード、地方自治体。
今でもクラシックなメインフレームで基幹系業務をこなしている会社をこのくらい知ってるわ。
言語はもちろんCOBOL。
部分的に一部機能は別のインフラを使ってるけど。 >>405
まぁまだまだCOBOLやメインフレームは良くも悪くも現役だしな
OPEN移行っていっても、売り止めの保険とかだと費用対効果で予算がつけられなくて
騙し騙し使い続けるなんてザラなんだがなぁ
ID:wjKFdtZ50は自分の見識をもっと広げたほうがいいよ >>2
頭おかしゅうなった老害客が和暦にこだわんねんもん で、新元号はまだかね？
女に媚びたような女々しい元号（愛とか優とか）だったら糞以下やで？
西暦以外使わんようにしたるわ >>406
膨大なシステム資産を新しいインフラに移行しても、メリットはあまりないからな。
SAPを導入することを生業としている身でなんだが、長い年月をかけてその会社に最適になるよう作り込んだ基幹システムを
ERPに置き換えて不便になって業務が大混乱している客を見ると胸が痛む。 もう書類も元号禁止にしよう。
そうしないとミスが起こるし、システムも複雑になるから 減価償却とっくに終わってる内部システムをまだしゃぶってるんだけど
素人がiniファイルをテキストエディタでちょちょいといじったら痛い目みる？ ちなみに何故か俺がとばっちりを食っているんだが
ちょっと古くて贔屓目なデータだけど
COBOLの全世界での稼働率は
ビジネスデータの75%
金融取引では90%
だそうだ
http://www.osscons.jp/osscobol/files/?action=cabinet_action_main_download&;block_id=414&room_id=21&cabinet_id=11&file_id=205&upload_id=410 現在の時刻合わせみたいに
元号はサーバーが管理して各自必要な時に問い合わせるorダウンロードすればいいんじゃないの？ ソースリストの中に”平成”という文字がちりばめられてるんですか？
とんだ地獄絵図ですね 文字列データ中の半角英数字を使用禁止にしているシステムは結構あるな。
一方、文章規則上英数字ば原則原稿一マスに二文字になってるところもまた多い。
某特殊法人では、この矛盾する状況で「黙認、無視」という解決策を用いてる。 まあ、IT屋って「このシステムに対応出来ないオマエラの仕事のやり方がワルい」とか本気で発言力しちゃうからなあ、頼むから明日の食い扶持のことも考えてくれとw >>420
バカには理解できないだろうけど
仕様書以外の仕事してももらえる金が増えるわけでないしな 頭おかしだろ？
平成になった後にもY2Kで年数の修正対応しただろ？その時に新元号も想定しとけよ 西暦と和暦でそもそもY2Kとは違うし、年に関する処理直してもついでに元号も対応する金を出さなかったのは客だからな。
2000年以降に作られたシステムだって沢山あるし、オフショアでそもそも日本人が作ってないのも増えてるからな Format(“eee年m月d日”, Date())
こういう発想はコボルなひとはできないの？ ここをちょっとやってボンってしてくれるだけで良いんだけど >>339
そのタイプなら今までのデーターにゼロパディングすれば拡張は容易かと。
データに手を入れられないなら、旧コードは都度変換で。 アメフトって日本じゃプロないし、社会人で続けても年収何てたかがしてれてるのに、なんで大学の部活でこんなに熱くなれるんだ？ >>431
あるあるだな。
元号じゃないが「それは○○マスターを直せばいいだけだから、システム改修は要りません」と豪語したのに、
プログラム内の変数に値をセットしているプログラムがあって、俺の面目丸つぶれ、かつ休日出勤で対応したことがあるわ。 >>430
(´・ω・｀)スクールカーストの頂点だからだろ >>432
必ずしもマスターデータに連動していい要件とは限らないからね >>403
SOMPOってシステム統合終わっているんだっけ？
終わっていないときついかな・・・
そういやMSADも終わったころか？
東海はさすがに終わっているだろうが >>417
日付データを元号付きで持っていると
和暦西暦変換したら2019年が1989年になっちゃったりする。
そうなると期間判定がアウト＝お金計算がアウト
というケースなんかもある。 >>436
SOMPOは一昨年辺りに統合終わってる
東海は日動とのならとっくだね
その後基幹システムを抜本改定してるからね
でもCOBOL使用w
MSADは超初期に上流で関わったけど、終わったのかなぁ、終わりそうになかったけど… COBOLはなぜ馬鹿にされるの？業務システム記述には
優れた言語だとおもうんだけど。 >>439
古いのはそれだけで馬鹿にされる対象になっちゃうよね
言語的にも新しいものほど思想が洗練されていきやすいし
何よりフロントエンド系は華やかだしw
バックでバッチ動かして帳票出すCOBOLの地味なことといったら… 役所の方がもう新元号をつかう気がないんだから、平成を延長してつかえばいいだけのこと。 帳票類がどうしてもなあ、新元号になった後も平成表記のままで客前に出さざるを得ないのがあるのがなあ
システム的には1年ありゃさすがにどうにか出来るけど 昭和から平成に改元した時に、既に本番可動してたシステムが今も動いてる場合は仕方ないが、
平成以降に新規開発されたシステムで、元号がマスタ化されてないのは異常だろ
開始日と終了日を持ったマスタになってれば、データを一行追加すれば終わりなのに
合字とかそんなもんは使ってる方がおかしい >>228
横だが画面や帳票への出力だろ
validater、service、BLで元号を扱ってるなら設計がおかしい 一ヶ月前とか対応出来ない業界とか出てくんじゃないの
印刷業とか昔程時間かからなくなったからまだ何とかなるのか >>442
絶対ある。
契約の満期とか継続関係は数か月前に発送するから。 根本的な改良を施そうとしても、客が
「広範囲の修正はするな」
「複雑なことはするな」
「金を掛けるな」
「人を使うな」
とか言ってくるわけよ
請負プログラムではね
現場にぶち込まれた人以外はピンと来ないと思うけど 先のことを考えてない馬鹿な設計者のせいだろ。元号に限った話じゃないよ。 金融はCOBOLでも元号変換のサブル－チンはアセンブラとかも多いぞ。 #define GENGO "平成"
え？修正？一行直すだけですよ？ システム内部は全て西暦処理で表面I/Fは和暦変換テーブルを使用するもんでないの？
元号対応はテーブルに1行付け足すだけだし… そもそも人間が理解できてない
最近法律関係で議論になったんだけど
平成32年から運用っていつだっけ？ とか 新元号になると決まってるけど文章どうすんのとか
西暦は連続性があるけど元号ではそれがない >>456
平成32年はたとえ元号が変わっていようと平成31年の翌年だろ。
そんなことで議論する法律関係ってなんだよ。ずいぶん程度が低いな。 >>454
必要な元号は1つとは限らない
例 2019年5月に2019年4月の最終営業日を和暦で表示する必要がある場合 >>459
☆元号存続VS廃止？？？
https://egg.5ch.net/test/read.cgi/sisou/1525346013/
元号制度
https://ja.wikipedia.org/wiki/%E5%85%83%E5%8F%B7
質問１→西暦2019年のゴールデンウイークを元号で表して下さい（出来ますか？出来ませんか？）
質問２→『元号裁判』佐野洋（激怒しますか？苦笑しますか？爆笑しますか？）
質問３→大化３年は何年前ですか？即答出来ますか？出来ませんか？
せめて公的文書だけでも西暦での発行を義務化するか元号と西暦の併記とすべきじゃね？ >>4
ソースコードどころか、変数に使っている某省庁受付システムすらあるんやで。 組み込み機器だと未だにシステムが昭和だったりする
そういう所では昭和100年問題に頭を悩ませる事になる 2000年対応のとき、影響が不明だったので
平成にしてたのが当時あった。
その時*”昭和”って和暦から西暦下2桁に改めてた履歴も見た。
まだ継続して使ってないか祈るだけ。 >>454
過去の2018以前のデータを表示する場合バグるじゃねーか障害表かけ 元号なんかいらんやろ
日本全体でこんなくだらんことに
何億何兆かけるんだ。
こんな無能だから日本人には仕事なくやる >>400
今では漢字2文字と決まっているんだよ。 >>440
でも、あの黒地に緑文字の画面はレスポンスがチョーいいんだよな。
あの速度は今時のツールじゃなかなか超えられない。
最初のとっつき難さはあるけど、操作に慣れた後の業務効率のよさは真似できない。
通信速度の安定しないインターネットを経由するクラウドアプリケーションは、あの手の軽い画面に戻すべきだと思うし。 免許証が平成34年までになってるので
元号が変わると分かり難いわ >>469
TSSやTSOだなw
あそこら辺はインフラのviに通じるものがあっていい >>446
常用漢字の中から選ぶとか、画数が極端に多くない漢字という前提があって、見慣れた漢字だけで構成されるから、
あまり古風な印象の元号にはならないと思う。
嘉吉とか、天慶とか、元亀とかみたいな元号は現代では選ばれない。 >>467
日本以外の国をまったく知らない人間ほど、こういうことを言いたがるんだよな。 簡単だよ
これが難しいなんて思ってる時点で
日本はもうＩＴ後進国
せめて皇紀にしろよ。
今日は、皇紀２６７８年５月２３日。
だちたい合字にする意味無いだろ。
そのまま「平成」で何の問題も無い。 >>1
なんで平成になったときに標準化しなかったのかと言いたいんだが？ >>474
難しくはないけどコストはかかるんだよね。
多分大丈夫だけど、一応一通りのテストをしなきゃならないからな。
30年間運用したことのない対応だから、ちゃんとテストをしないと漏れが起きる。
テストにはそれなりのコストがかかる。
前回の「平成」対応時に、今後の事考えて、
次の元号が来ても簡単に組み込めるように、
作り込んでると思うんだ。 >>480
いやいや。俺はソフトメーカーじゃないし。
具体的に>>479のどこが間違ってるのか指摘してみ。 これからは皇位継承者誕生した時に将来の元号も合わせて発表したらいいよ
改修の時間的余裕が生まれてカレンダー業者も大助かり
秋篠宮の元号は〇〇
悠仁に元号は△△って具合にな >>481
平成元年てまだそれほどパソコンは普及してなかったからなあ。
それにしても改元で大慌てするようなシステム設計はありえねえな。
フォントに割り当てとか何考えてんだ。
ソフトの環境設定に、「元号追加」と言う項目位、
作ってあるのじゃないか？ 元号の悪いとこは1月1日午前0時0分0秒に切り替わるわけじゃないから、
1989年が昭和64年だったり、平成元年だったりするとこ。これがまた複雑化の
要因。
ソフトの環境設定で、新元号の初日を、皇紀（まあ西暦でも良いけど）で定義すれば、
それ以降の処理には、それを利用するので問題ない。 >>404
その辺は閣議決定かなんかで平成元年一月一日が有効な日付として使えるようになってる。 >>482
この程度のシステムテストになんか時間掛からん
昔と違いテストも自動化出来るんだし >>486
まともなソフト屋と注文者ならそうしてる
今回の件は民間銀行などは混乱起きないのは確実 社内システムのCOBOLソース5000本が（西暦-1988のような計算で）
独自に西暦和暦変換をしていて、全て修正・コンパイルし直しが必要という絶望的な状況
なぜ平成の時に本格対応しなかったのか、30年前の担当者たちを問い詰めたい >>493
だよね～。
俺も若い頃は、「西暦で良いだろ！」と思っていたが、
年重ねると元号と言うのが、時代を知れると言うか
味わいが有って良いと思うように成ったわ。ｗ >>494
エディターのマクロプログラムで、ソースを
一括変換出来るように工夫してみては・・・。 H,平成,19890108
みたいなプロパティファイルあったからそれに追加するだけだったわ
工数かかるっていってるところは金だけ要求する無能の集まりなの？ http://koyomi.vis.ne.jp/doc/mlwa/200708020.htm
＞ 1912年7月30日は、明治か大正か？
＞明治45年7月30日と大正元年7月30日が在ったようですが
＞ これはどの様に使い分けているのですか。 簡単だろ
技術というか知識が無いから難しくなってるだけのような >>497
まともな所はこの30年の間のどこかの更改の機会にやってる
ただ、そういう事を先送りしてやってこなかった無能な連中が慌ててるだけ >>9
改元を意識した設計にすると、
「いつ起こるか分からん処理に金は出せん」
と言われて、その分値切られますが？ >>492
「この程度の」って、どれだけの規模のシステムか、どういうインフラのシステムかも定義しないで、
よく時間がかからないなんて適当なことをいえるもんだ。
アホ過ぎて笑えるわ。 >>503
じゃあおまえの想定してるシステム言ってみ >>504
「システムを言う」って意味がわからん。 >>504はシステムの名前を聞くと規模や構成がわかるんだろうか？
すごい 消費税はなあ
発生年月と計上年月とかの関係がめんどくさいよな >>500
まぁほとんどこれ
昭和が長かったから次は短いだろうと思われてたけど
結局は10年後だか20年後だかにやればいいやー
もしくはその頃はもうこのシステム使ってないだろー
ところがレガシーは生き残り続け、時間や予算がなかったために皺寄せが今来ている 問題があったらHとかの英語一文字でいいだろ。 被らせる方がおかしいしアタマいかれてる。 >>510
閏年を導き出す計算に「4の倍数の年」という計算だけのシステムも多いよ。
西暦2000年は4で割り切れるけど、400でも割り切れるから閏年だから、
「100で割り切れる時は平年」というロジックが適用されるのは2100年にまでないから、100年以上先のことは無視してる。 >>494
30年前は一つのシステムが30年使えるなんて誰も思ってなかったからな。
パソコンが2年で旧式になり五年で使い物にならなくなる時代。ウインドウズ以前の98全盛期だもの
68kが出たばっかな時代だぞ。 >>505
「想定してるシステム」
日本語読めないって辛いね >>514
「想定しているシステムを言う」というのが日本語として成り立ってないだろ。
システムの何を言うんだよ。
小学生かよ。 昭和を前提として動いてるシステムが今もあるとは驚き
分野は銀行系？ 聞きかじっただけのなんちゃってSEが多いスレだなw
もしくは新人のペーペーか >>515
おまえが日本語読めないのがよくわかったよ
と言うかアスペかよ >>518
答えられないと人格攻撃か。
憐れだな。 >>518
いずれにせよシステム規模なんてユーザによって千差万別なのに
この程度のシステムテストってのは全く意味をなさないよ >>519
前提というか、プログラムとして年号部分の引数が二桁しか想定してないというべきかな
データの箱の大きさ考えたら６ビット以上はあるんだろうから、
昭和127年までは対応出来そうだが >>518
君は想定しているシステムを言えという質問に何を答えるのかな？
(A)UNIXを想定しています。
(B)経理システムを想定しています。
(C)うちの会社では「PEACE」と呼ばれているシステムを想定しています。
(D)クラウドシステムを想定しています。
問いが漠然としすぎていることに気づけないのか？ 最初から西暦にしておけばこんなことにならなかったのに、やっぱりジャップってアホだね
ITのレベルも低いわけだよ >>520
お前の想定しているシステムがどんなのか言えと言ってるんだが？
それ以上どう言えと？
アホは辛いね >>524
この会話のなかでその答えをするような池沼とは思ってなかったがね システム内部で元号を使ってるとかあるの？
西暦で管理して表示だけ元号でしょ？ >>523
一代の天皇が100年以上君臨するというのも考え難いけど、そうなったら御退位あそばしていただいて、改元すればいいと思う。 >>479はまともなこと言ってると思うわ、何かしらのソフトに関わった仕事してる人ならたいてい考えること >>528
君は、自分の脳内をみんなが理解していると思ってるんだな。
「どんなの」なんてのも漠然とし過ぎだな。 >>527
うちはCENTRAGEIIと言うシステムなんですけどどうしたら良いですか >>528
たぶん、システムに関わる仕事をしている人のほとんどには、池沼は君の方だと見えてる。 まあシステム屋さんは、動作テスト項目の検討には入ってるんかな？
具体的な値は分からんでも大、中項目レベルなら今からでもできるでしょ
あとは試験時間の確保か？来年五月の連休休みあるの？ >>532
君はこのスレを読んでなぜ>>524のような回答が的確だと思うの
話の流れをすべてかいた上で詳細に質問を書かないと回答できない低脳なの？ 西暦ー和暦変換で昭和→平成は昭和64年が数日だったから単純に昭和64年を平成元年と表示しても大した影響なかったけど今度は4ヶ月違うからな
つまり、表示するだけでもちゃんと年だけでなく月日計算しなきゃならないし、何より年度の問題があることも考えとかなきゃならない
つまり、平成31年度が1ヶ月間存在するということだ >>527
うちの会社はIBM z14システムなんだけど、どの程度ですか？ >>536
スレは全部読んでるけど、システムのなにを言えばいいのか、私には皆目見当がつきません。
上の例はどれも妥当な例だと思って書いているよ。
君の脳内とはズレているのかもしれないけど、君の脳内とシンクロしている人はこの世で君一人だけ。
少なくともこのスレには君以外は一人もいない。 難しさが理解できない。
内部は西暦で管理、表示用の和暦変換は定義ファイルを用意する。
OSレスのシステムで和暦が必要とは思わんし、これで全て解決では？
それとも役所の時計は全て和暦表示なのか？ >>541
難しくはないよ
上でも言われてるけどシステム規模に比例して工数がかさむだけ
外部接続とかあったら、接続先と調整してテストやら何やらも必要になってくるし
まぁ面白くもなく疲れるだけだからやりたくないね 和暦もだが、消費税の税率アップも変更日とそれ以前では処理が違うから
プログラミングが面倒だわ
商慣習によって社外への請求と車にでの売り上げが上がるタイミングが違ったり
返品処理時の消費税計算をどの時点の税率ですべきかとか、個別案件対応になる >>114
二文字分適当な文字で用意して位置調整出来ないの？
後で文字を置き換えるだけでよさそうだけど？ >>541
たぶんテストが大変
改修箇所が事前に分かっていても、元号発表から１ヶ月で、
単体テストからシステムテストして、途中バグ改修もして納品なんてやりたくないわあ >>541
新規システムならそうだろうが
過去に色んな扱いしてるシステムが混在してるから、対応が複雑
>>1に書いてるだろ >>4
あるなぁ
当時ここまで生き残ると思ってなかったシステムとかそういうの
2000年問題の時に直せるものは4桁にしたけど出来ないものもあったわけで 昭和から平成に変わった時代と違って、今はシステム関連は複雑になってるからな… >>542
＞外部接続とかあったら、接続先と調整してテスト
メンドイのは、この部分だね。 せめて3ヶ月前には公表しろよ
生前退位なんだから不敬でも不謹慎でもないだろ >>542
ああ、外部IFに西暦使ってると厄介だね。
でもそれは、IFだけの話では無いが、改元を想定せずにシステム発注した役所の無知と怠慢を責めたいな。税金が幾ら浪費されているのか、、、 >>548
どこの会社も、システムの増築を繰り返していて、いろんなパッケージや、領域システムがたくさん入り込んでいるからな。
前回の改元で対応経験があるシステムなら、ドキュメントが残ってるけど、改元以降に導入されたシステムは「どこを修正すればいいんだっけ？」から始めるからね。 長年って、昭和から平成に代わるのを乗り越えてきたくらい長年使ってきた
システムなら平気だろｗ
それ以降に作った奴なら改元を想定してないのが悪い
当たり前 こんなこと考えずにプログラムした奴がバカ
初めから分かっていたこと
作る時から考慮し対応できるプログラムを書くべきだった
今頃騒いでいるのはのうたりん
ところで、MS-DOSの限界点の日時（寿命）はもう来たのかな >>554
「先月やった」「去年やった」くらいなら簡単なんだけどな。
30年前にやったとなると、それをやった人たちはほとんど会社にはいないし、やった人も忘れてるし。
対応はしていても、担当者としては初めてやるというケースが多いだろうから。
漏れはないか？と言われても、誰しも自身は持てないから、テストは時間をかけさせてくれということになる。 >>556
何をどう変えたってテストは必要じゃねーの？ >>419
使用禁止というより
シフトJIS以外のシステムは混在無理だろ >>558
UTF8やEUC-jpまで無理なの？
コード的にはsjisと同じような作りなのに >>556
30年前から同じシステム使ってるはずないだろw >>560
そう油断して起きたのが2000年問題だったからなぁ… 嬉しいのはITゼネコンとコボラーだけ。
中小はJavaとかクラウドとかパッケージソフトとか使ってるから、あんま関係ない。 >>557
テストが必要か否かの二択なら「必要」ということになるけど、ケース数が違ってくる。
このシステムはこのマスターを修正するだけでOKという絶対的な自信があれば、帳票を1枚出せばおしまいだが、
領域ごとに別のマスターを設定しているかもしれない、プログラムに直書きしているバカもいるかもしれない、
本社営業日のカレンダー、工場稼働日のカレンダー、納品受入倉庫のカレンダーごとに別のマスターが存在したりする
アホな設計になっていないとも限らないとか考えると、テストケースが増えてしまう。
前回の請求書ではまだ新元号が未定だったから平成31年となっていたけど、何ヶ月か後に再発行した請求書では、新元号が決まっているのに平成31年のままでいいんだろうか？
(請求書を初回に発行した時に蓄積したデータも元号変換し直さなきゃダメか？)
とか、やり始めると色々出てくるんだわ。 >>560
オフコン使ってる中小企業とかいくらでもあるぞ >>563
だからさ
想定して作ってないのが悪いんだって
ベタ打ちしてるプログラムがいっぱいあるんでも限り影響範囲の特定はできるだろ >>560
50年前から同じシステムを使っている会社も沢山あります。
COBOLプログラムのauthorを見たら「これ、先先代の社長じゃん」みたいな。 >>566
そもそも悪いからなに？
想定していても、30年間一度も使用していない機能は誰にとってもリスクを感じるだろう。
「想定」なんて幼稚な言葉では何も解決しない。 >>569
悪いから、頑張って改修してねってことだよ
それ以外にないだろ
「悪くないから直さない！」ってわけにもいくまいに 元号は「プレゼンテーション用の編集様式のひとつ」って事を理解してて、西暦、或いは、ユリウス暦でデータ項目を構築していれば、こんな問題は発生しない。
入出力の変換サブルーチンやファンクションを1つだけ用意すればいいだけの話である。 >>570
頑張って直さなきゃいけないというのは、>>1の通りじゃん。 >>571
組織内のすべての仕組が同じシステムに入っていればね。 >>9
日本はIT後進国だからな
日本人には難しい、というだけの話だよ >>572
>>1とお同じこと言ってる俺になんでそんなに必死に絡んでくるのか… この機会に対応できないようなシステムは駆逐されたほうが後々の為じゃねえの
景気いいんだろ、いま設備投資しないでいつやるんだ >>575
俺は、良いか悪いかなんてことを言った覚えはないのに、>>566に絡んできた人に言えば？ >>426
その、Format関数は誰が改修するの？
恐らく開発言語メーカーだろうけど、新元号発表直後に対応してくれる保障は無いし、
仮に対応してくれても現行のシステムで問題が発生しないか、テストするのはシステムを作ったメーカーであることに違いはない。
今から一年かけて備えるのと、新元号発表を待ってさらに開発言語メーカーが対応してから残された一ヶ月弱（実質一週間弱？）でテストするのでは、
どちらも地獄には違いないが前者の方が若干マシ。 >>581
俺に最初りレスしてきたのは、>>557だと思うが？ >>582
じゃあ最初のレスをアンカしろよ紛らわしい ないと思うが、新元号が2文字以上とかはあるんだろうか？ >>583
なぜ横から入ったおまえにレスしなきゃいけないんだ？
これに関しては絡んできてるのはおまえだよね。 >>585
お前が意味不明なレスしてるからだろ
これに関しては間違えてるのはお前だよね UNIX TIMEがもうすぐ改訂に為るのに和暦止めて西暦に統一とか池沼
改訂後の計算機時間だけ標準にして和暦も西暦もオプションに括り出すのが正常な頭の持ち主の結論だろ
公定計算機暦とか作って月の概念を廃止して年日だけにすれば現行より一桁少ない７桁から全てを表示をできるから
年を一桁増やしてクロマニョン人まで通しで勘定するも好し
或いは余った桁を利用して正負記号付き年日表示にするも好し
なのに何で皆頭悪いの？ >>586
どこが間違いなのか具体的に説明してもらおうか。 >>342
皇室がただのロイヤルファミリーに成り下がっているのが悪い 難しいんだな？難しいんだろ？
内部で内部の対応表通りに機械的変換を行って出力する部分を持つAIで、
ヒューマンエラー内蔵の認定を受けるAIの実例はよ 世間一般では2000年問題騒いだ割りに大したことが無かったと思っているんだろうな
裏でIT土方が苦労していたなんて知らないだろうな 簡単じゃない、簡単じゃないと営業を必死にかけているだけだから。
ぼったくりだよ。 元号修正はどこも想定してるだろーけと
元号廃止まで想定して作ってるとこは少ないだろーな
まさに寝耳に水だわwwww >>594
いや。考えたことがあるよ。
もし元号が廃止されたら、「西暦(さいりゃく)」という元号になったと思えばいいと、思ったりもしたんだが、
新元号が1年から始まるんしゃなくて、19年からスタートしてもいいような対応はどのシステムしてないわ。 設計時「改元に対応できるようにすると次の改元のときにもうけられないからなー」と
改元を意図的に無視した設定にしていた？ 古いパッケージを少し無理して使っていた所では、
「古すぎて対応できません」と、そのソフトのメーカーに一蹴されるケースが頻発するだろうな
古過ぎると、コンパイル環境すら作れない場合があるんだ >>573
こういうサブルーチンやファンクションは「共通業務関数」として管理されるべきもので、同一法人システム内に複数管理することが、そもそもおかしい。
(ただし複数システムの各々の開発基盤か異なるならば、複数言語での並行管理は必要になるが)
仮にアウトソーシングしていたとしても、根の部分までアウトソーシングするならば、申し送りしておく必要がある。
バカな企業が単にシステム部要員を減らたいがため、そういう「システムの根」に関わる部分を十分に押さえないで、アウトソーシングするケースが目立つ。
自社システム内で自社保守の範囲でこの事象が起きているならば、CIOが無能過ぎるとしか言えない。 >>598
＞こういうサブルーチンやファンクションは「共通業務関数」として管理されるべきもので、同一法人システム内に複数管理することが、そもそもおかしい。
それは、おかしいか否かではなくて、理想的か否かですね
経理はSAP、受発注システムはIBMのメインフレーム、生産管理は富士通のパッケージ、各支店は別々のシステムみたいな企業ばかりです
今時、世界のどこの企業も、企業のすべてのシステムを一つのノードに載せているなんてところはありません
30年くらい昔なら、全部がメインフレームにのっかっていたけど、今はどこの企業も複数のシステムの寄せ集めになっています
他社にはご高説を垂れるIBMですら、社内システムは複数のシステムの寄せ集めで、元号ごとき瑣末な項目の集中管理などされていない
何十年かに一度出番が来るような仕組みに金をかける企業はほとんどいません
そういう仕組みは何十年前かに一度バタバタ大慌てをした方が安上がりですね
システムを導入してから捨てられるまでに一度も出番が来ないかもしれないことに金をかける企業は賢いとは言えません >>1
さすがに和暦でソートは無いわｗ
西暦でソートしたの表示だけ和暦でしょ
UNICODEも合字とか対応しなきゃいいのにヤヤコシイ
まあこういう時に儲けるのは、富士通・NECと相場が決まってるんですけどね 内部処理に元号使うバカな設計がおかしいだろ。
アウトプット用にだけ使えよ。 >>573
各システムごとに仕様が分離してても、
各システム毎に1ファンクションの変更だけで対応できるのと、内部のメインロジック見直す必要があるのとで大きく工数が違うだろ。
なんで内部ロジックで和暦なんちゅう不便なもん使ってんのよと。 >>318
今の制度では外国人でも定住者は住民票に載るんだよ。 >>603
＞内部ロジックで和暦なんちゅう不便なもん使ってんのよと
俺は内部ロジックに和暦を使うなんて話は微塵もしていない。
反論は俺が書いていることに対して行ってくれ。
俺は
＞入出力の変換サブルーチンやファンクションを1つだけ用意すればいいだけの話である。
に対して、１つだけなんて夢見たいなシステムはないと言ってるだけ。 仮に３０年前に、平成の次の元号まで考慮してシステムを
改修・テストまでしてあって、今回もほんの少しの修正だけで
対応が終わるものとしてみよう。
「昔の人は偉かったなあ、感謝感謝」
「うちの出入りの業者には感心した、金一封贈呈しよう」
と考える人は誰もいない。
悲しいことにこれが現実なのだ。 まあ現実問題、SQL ServerとOracleでも『日付（西暦）』の持ち方違うからな
これにPostgreとか来たらまあ大変 要領が足りないから使わない漢字や外字削って無理矢理プログラム突っ込んでたような時代に
「将来また天皇が死ぬかもしれないから新しい元号用のスペース作っときますね」
なんて提案するSIは当時からしたらキチガイ扱いだろ 和暦なんか止めれば良いのに、ネトウヨが文句言うからなあ
IT土方なネトウヨは自分のクビ締めて喜んでる変態だし 和暦しか知らないお年寄りとかいるから、そういうのが客なら対応するしかない >>511
うちは30年前の人達が今までの30年間バラバラに作ったから
似たようなシステムなのに作りもバラバラ。
日付とか、それぞれのオリジナル。
今回の為に1個だけ共通関数作って
そのバラバラのやつから、日付っぽいのを見つけ出して
共通関数をかます。
その分テストも多いよ。
共通関数を全部調べてそれぞれを作り直しすれば、もっと簡単だろうけど、
改修の時間が殆んどないから、無理。
パパッと作って、ﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞと噛まして
ﾀﾞﾀﾞﾀﾞﾀﾞﾀﾞ∞とテストする。 >>511
顧客「なんで1文字しかないんだ？2文字や3文字もありうるだろ！」 「将来を見据えて作れ」と言う人が「そこは1文字固定で」と言うのはちゃんちゃらオカシイ。
将来、つまり、次の次以降、いつかは3文字になるかもしれない。
多分、それが客の言いぶん。
将来を見据えろとか言ってるんなら
ここは固定にはならないよね。 西暦1万年問題、とかなら先の世代に先送りってのもわかるけど
昭和100年で先送りってどうよ
極めて近いうちに、誰かがすごい死ぬ思いするってはっきり未来が見えるじゃん
少しずつ移行のための仕様書作っていけてれば 良かったのに >>562
ベンダーやパッケージ依存は
そいつらが対応するまで待たなきゃならないじゃん 新元号は、半角文字で「=2018+」にしよう。
エクセルなんかで便利になるぞw 元号の重みに比べれば、昨日今日のシステムなどは羽毛の軽さだ。
改元についていけないようなシステム屋は、自分の無能さに恥を知れ。
日本国の国体を護ることに貢献できてこそのシステムだろ。ちがうか？
お年寄りがどうたら、面倒くさいからどうだとか、本末転倒もいいところだ。
システム屋としての誇りはないのか。ワンタッチで対応できるよう全知全能
をかたむけ、不眠不休でプログラミングにとりくむべし。 >>454
２０１８年を（新元号）０年と表示してしまうバグの出来上がり ここまで苦労して機種依存文字を使うぐらいなら、
もう全部手書きをスキャンした画像データでいいよ >>622
いや、（新元号） 30年になってしまうんじゃね？
>>454だけだと >>1
あーだこーだできない言い訳をこねくり回す無能の典型
そんなに難しい作業の訳ねーだろｗ
三沢みたいな香具師だな 中には難しい言われてるようや難しいパターンもあるけど、大抵サクッとテスト環境のマスタ修正して正常動作のエビデンス作って終わりだろ。
役所や大企業はシステム屋の口車に乗せられるなよ。 乾杯をしよう 若さと過去に
試練の時は 今終わりを告げる
血と鋼の意思で 敵を追い払おう
奪われた故郷を 取り戻そう >>626
頭を使えよ。
システムがデカイと、そのサクッを何千回もサクッサクッサクッサクッサクッサクッ……しなきゃならんのよ。 >>630
昔に設計されたCOBOLがやっかいなんだよ >>630
表示だけでは済まないからやっかいなんだよ
2019年は、平成31年でも、新元1年でもあるからな
日付情報がないと、どちらか定まらない 先々の事考えたら、一時的に費用は掛かるけど、COBOL作のシステムはリメイクするべきだ
開発のし易さ、マの多さ、資料の多さ、将来性などを考えたら、C#辺りでさっさと作り直すべきだ
早くしないとCOBOL使える爺さん達が居なくなっちまうぞ >>633
基幹系データの扱いやすさ、数十年に渡る安定性、その他諸々を含めて経営判断として
未だにメインフレームを使ってるところが多いんだよ
思いつきでリプレースとか顧客に行ったらボコボコにされるぉ？ >>41
あとでまた仕事が発生するように、気づいてもあえて対策しないのがマトモな奴です。 >>632
表示だけで済むよ。
データベースには西暦年月日を格納して、それを画面や帳票に表示するときに和暦化すればいいだけなんだから。 >>633
＞開発のし易さ、マの多さ、資料の多さ、将来性などを考えたら、C#辺りでさっさと作り直すべきだ
そんな定性的な主張だけで予算が認可されるような甘い企業ばかりじゃないんだよ。
それらを定量化して、一時的な費用を上回る利益が生じることを示さなきゃ予算はつかない。 今時time_t使わないなんてありえんし、今年中に改元することになるかもしれんし、どうでもいい記事だな なんかごちゃごちゃ理由書いてるけど、平成が未来永劫続くとでも思ってたのか。
平成の後のコード、予め数個空けとけよ。 気持ちの悪い合字なんか使うな。フォントをまた買わなきゃいけなくなるじゃねえか >>636
君みたいに軽く考えてる人には仕事を任せたくないｗ
俺わかってるからすげーからってアピールしたがるやつに任せるとろくなことにならんｗ
うっかりしてましたではすまんよｗ >>634
マイグレが進まない理由に安定性があるんだよね
何十年と動かしても保証されてる環境なんてそうそうないわけで >>644
君みたいに、難しい理由を論理的に説明して相手を納得させられない人には仕事は委託できないな。 >>645
そだねー
安定してるシステムをマイグレーションしてサービスイン、バクの連発、改修に次ぐ改修、そんでデスマーチ
下手したら損害賠償
やりたくねーw 平成で天皇が退位するということで
『 平成譲宝 』
とかだったらどうだろう。つまり漢字４文字www >>649
Hがかぶるからそれはない(大正改元以降ちゃんとそれも考慮して元号は選ばれている)
まあ四文字元号復活はおもしろいっちゃおもしろいが
ところで上皇さんの誕生日はどう扱うんだっけ
>>646
>>1に素人向けに細かく書いてあるだろ 和暦で登録したデータを数千あるファイルから日付項目探して西暦に変換とか気が遠くなるな >>650
1の話ではなくて、
>>632 ＞2019年は、平成31年でも、新元1年でもあるからな
＞日付情報がないと、どちらか定まらない
という話は単純に表示だけの話だよ。 >>652
＞単純に表示だけの話
ここを詳しく説明して
たとえば、女の子が平成31年生まれか新元1年生まれかは、正しく表示しなきゃいけないでしょ 将来のことも考えて設計してなかったバカってだけじゃん？ >>651
どのみち西暦年月日にしても和暦変換のアルゴリズムは同じ話
システムや関連ファイル・ソフトが誤作動するからどうしようもない >>651
一般企業の実務上は明治からの登録でほぼ困らない
金剛組はどうしてるのかは知らないけど >>657
通称「下駄」はとりあえず表記できない文字を埋めるのに使われてきた経緯があるから
まあ合字の代用としてはアリだろう >>653
和暦の範囲をデータベースでもプログラム内でも登録しておいて
その日付がどの元号に当たるか計算すればいいだけじゃねーか
ソフトウェアのことを何も知らない人かな？ >>653
西暦で登録しておけば、そんなの簡単じゃん？
女の子の生年月日はわかってるんだろ。 unix時間じゃなくて文字列として時間情報持ってるの？
ちょっと何言ってるのか意味分からない
そんなことより、入力画面のラジオボタン追加とか、
印刷用レイアウトの修正とかの方が面倒くさそうなんだが >>1
元号は絶対残すべきだけど
形式として残せばいいんじゃね
いちいち元号書かせる書類はウザいのでやめてほしい >>662
unixじゃないもっと古いシステムがゴマンとあるのに
何故当然のようにunix時間で管理してると思い込むのか不思議 >>662
銀行とか、高炉メーカーとか、自動車メーカーとか、昭和40年代から本格的にシステムを導入し始めた大企業の多くは、
今でもその時代から作り続けてきたメインフレームの資産を使い続けているんだよ。 >>659
その日付け情報が近くにはない場合、ロジックの追加が必要になるでしょ？ >>661
限られた例を示したに過ぎないので
日付情報が近くにない、あるいは日付情報を元々持っていないというケースはかなりあると考えられる >>665
そっち系の仕事はしたことないから、あんまり想像出来ないです
想像したくもないけど
ハードはどうしてるんですか？仮想マシン？
ハードから開発環境まで、全部保存してるんですか？ >>667
日付情報がなく生まれた年月しかわからないなら、その月の1日の和暦を採用するなどという決め事を作ればいいんだろ？
その手の決め事は、昭和が平成に改元されたときにもあったんだから、大騒ぎする話ではない。 だから和暦なんか不快で不要
西暦で統一すれば良いだけ
国際社会に向け西暦で統一すべき
和暦は好きにしたら良いけど、正式には西暦で統一すべき
和暦は歴史的産物として続けたらいい >>668
ハードはどんどん新しくなるよ。
そんなのはUNIXだってWindowsだって同じことだろ。
30年前にUNIXで構築したシステムといっても、30年前のUNIX機、30年前のUNIXバージョンを使い続けているわけじゃないだろ。
メインフレームだって同じ。大昔に作ったソフトウェアを最新のメインフレームマシン、最新のメインフレームOSで使っている。 k&rだっけ？もう名前も忘れたけど
私がプログラム覚え始めたころ、古い規格で書かれたのc言語のライブラリがかなり多くて
それを最新の開発環境でコンパイル出来なくて辟易した記憶がある
パッケージ管理システムが導入された時代のシステムでも
古いライブラリが手に入らなくて困ることが多々ある
糞面白くない仕事
まぁもうプログラマ辞めちゃったので、関係ないけど
そのあたりの苦痛は理解できないではない >>669
取り決めが重要なのは、その通り
昭和64年は、七日しかなかったうえ大半が正月休みだった
ビジネスにはあまり影響なかったんだな
それに、IT化も進んでいなかったし >>668
昔行ったところはハードはどこか大きなところから時間で借りてたな
時間つっても処理時間でだけど
「お前の作ったプログラムが無限ループで数百万の損害が出た」
って怒られたことがあるｗ >>673
正月休みか否かなんて関係あるか？
それに、平成元年当時のほうが今よりもっと大変だよ。
コンピュータというものが登場して初めて経験する改元なんだから。
パッケージシステムなんてものもほとんどなかったから、各社それぞれに個別に対応しなきゃならなかったし。 これはここ15年でソフト始めた奴とその前からやってる奴でイメージが全然違うだろ
メモリー単価などが圧倒的に安くなりソフト構造が飛躍的に進化したから
今の小学生がやってるようなプログラミングしか知らないと
なんで難しいシステムもあるって言ってるのか理解できない >>676
プログラマならそれでいいけどね
SierでSEやってまーす、とか言ってるんならそれじゃ使えんよ 対応はどれも簡単。
問題は個々の対応の難易度ではなく、量が多いことなんだろうな。
量が多いから、すべてを漏れなく確認することに力が必要になる。 >>678
2000年問題のとき、印刷された連帳の束を渡されたなぁ… 今から直しておけば？
元号は「驫驫」とかにしておいて、決定次第「新元号」に置き換えれるようにプログラムしておけば良いんじゃない？
また、仕事量が多いときはAIにやらせるとか。 入力チェックで帳票に「元年」って入力するやつがいるから、元って入れたら
１に変換するのは常識だとかなんとか言われて、しょうもない変換ロジックを組
んだのを思い出した。
これって常識なん？ >>675
＞パッケージシステムなんてものもほとんどなかったから、各社それぞれに個別に対応しなきゃならなかったし。
全量が今に比べればはるかに少ないし
間に合わなくても手で何とかってことができた時代。 >>668
ハードは新しくなっても動作はほぼ保証してくれる
だから古い資産が当たり前のように動くわけで >>662
官公庁は今でも和暦が基本かつ、紙ベースでやりとりしてるものを、システムに取り込む
ので、最近作られたシステムでも、少なくとも取り込んだ時点では和暦形式の場合が多い。
画面表示も和暦。DBに格納するときはさすがにDate型で入れてる。 てかマジで昭和年数で作ってるシステムあるから
根幹から作り直さんとマジヤバいの結構あるんだよなあ >>685
Date形式とか最近のシステムの話をされても >>685
てか官公庁は統一されてなかったんじゃなかったか？
このたび全部根幹は西暦(グレゴリオ暦)で統一しますってスレ立ってたろ ソフト屋ならわかんねん
どう見ても簡単やんと思う仕事が仕事として存在し続けてるのは絶対に理由があんねん… >>690
あるある
リニューアル管理をナメてるやつはド素人 >>642
「元号変わる頃にはこのシステムも俺達もいねーし」って思ったんじゃね？ >>2
賛成。
元号は儀式的な場面だけで使えばいい。 >>659
それしか想定できないって、お前大学生？ >>693
平成は長くないって気づいててもそれを口にするのはタブーだから結果的に先送りされたってのもあるかも。
90年代あたりまではその辺の感覚が強かった時代だった。 元号をぎりぎりに発表することは
元号が使われなくなる原因になるのに
なに考えてるんだろうねえ >>698
新元号名に対する反対意見を封じ込めるため。
でも裏目に出て以後、元号が西暦にとって代わられると思う。 >>681
ダミーデータを入れると必ず怪しいお米セシウムさんのような事態が起きる >>599
複数のプラットフォームで異種のシステムが稼働していても、抑えるところや譲ってはならない部分を考えれば答えは明確になる。
パッケージや半パケでも同様。
もしパッケージや半パケの対応に膨大な時間がかかるのなら、それらは捨てる方が早い。 ビューやプレゼンテーションの問題だからな
ロジックは西暦使ってりゃいいわけだし >>702
意味不明の抽象的な反論は無意味。
その明確な答えとやらを示してみ。 えっ？
平成の対応の時に二度とこんな下らない仕事をしたくないから、以降は納入の担当者で対応出来るようにしたぞｗ
受けるとしたら動作確認だけだけだからテスト屋に投げるｗｗ 皇紀は成り立ちからして西暦のパクリだから存在自体が国辱 ジャップの事だから元号変更で商売が儲かるようにワザと手間がかかるように作ったんだろ
その言い訳が元号変更がいつ発生しても良いようになどという注文は受けていないから実装しなかった云々 >>706
昔はそんなことよりいかに軽く小さく作るかが命題だったんだよ
a*10よりaを10回加算したほうが速いとかそんな世界
関数なんてとんでもない >>706
ほとんどの企業は見越して作ってると思うよ。
でも、見越して作っていても、30年間使ったこともない機能だし、
30年の間に新しいシステムも作られているし、どことどこに新元号を設定すればいいのか、整理するのが大変。 >>710
年4桁が大きいから下2桁でいいって時代だったしな >>697
国民としての良識がまだ生きていたからね。現在はめちゃくちゃだよ。
改元当日に発表でいいと思うんだよね。 >>58
1階をGroundfloorなんてもってのほかだと？ >>712
昔はストレージのコスト高かったかなぁ… >>715
データベース扱うにしてもメモリが少なかったしね レコードの大きさにキツイ制約があるのは普通だったな
たとえば、全銀フォーマット＝120バイトとか 実は何の問題もない。技術者はみんな分かってる。
来年はスムーズに移行する。
政府はそれを分かってるから妥協はしないだろう。
騒ぎたい奴が騒いでるだけ。問題ありと言ったもん勝ちというだけ。
誰も死なない。 頻繁にエアブレーキで故意に騒音をばらまき近隣に迷惑行為をかける南砺市営バス運転手。福野、井波、井口循環線（右回り、左回り）
大きいものだと爆竹程度の音がする。 集団ストーカー。 被害歴４年。ﾅﾝﾊﾞｰ1032
集団ストーカーとは権力者（警察・消防）が大勢の低民度市民を使って特定個人にいやがらせする犯罪です。
南砺市地方創世推進課、担当；吉田さんに5度、被害を訴えるも未だ止まず。被害を訴える以前はほぼ毎日やられていた。
最近のエアブレーキによる騒音被害・・
2018.1.5(復11.13爆) 1.9(16.21) 1.15(復8.25) 1.17(18.00) 1.18(11.13爆 12.53蒸し) 1.24(16.31、18.06) 2.1(17.54) 2.2(16.20、18.00)
2.7(18.10) 2.8(14.57爆竹並み) 2.21(16.20、17.57) 2.22(8.23蒸かし) 2.26(16.21近所の爺の咳払いと連動、17.57特大) 3.7(16.16特大)
3.8(14.53特大) 3.13(16.18、17.55) 3.14(16.20、17.55) 3.19(12.53大、16.17) 3.22(17.56) 3.27(16.18大)ﾍﾘと連動 3.28(14.53蒸かし)
4.4(16.20) 4.5(16.16) 4.10(17.54) 4.12(16.16) 4.19(18.00) 4.23(17.58) 5.9(18.00ﾍﾘと連動)
5.17(17.55大) 5.18(14.53復) 5.22(16.20大、17.59大) 5.23(復12.53蒸かし) 5.25(復14.54大、16.20大)
集団ｽﾄｰｶｰに加担する犯罪者； 全国のみなさんにあほｽﾞﾗを見せてあげましょう。
http://fast-uploader.com/file/7082788709791/ >>720
2000年問題のとき、死ぬ寸前までいったSEが続出したのを知らないだろう >>3
こういう低脳PGがいるからシステムが止まる。 西暦なんかあと100年持たないよ
数十年後にはイスラムが多数派になるのは確定してるし >>723
イスラム国はどういう暦を使ってるんだい？ 合字使わなきゃええやん。
西暦何年何月何日何時何分から西暦何年何月何日何時何分までがどの元号って配列作って入力された日付を照らし合わせるだけじゃん。 >>725
合字は、ほとんど使われていない特殊な例だぞ >>724
ヒジュラ暦。
太陰暦なので、一年が365日ではなく354日なので毎年約11日づつ年の始まりがズレていく。
だから、1月が冬とは決まっていない。
ラマダーンも太陽暦に対して毎年11日づつ前倒しになる。
一年中大した季節変動がなく、栽培農業も行なっていないアラビア半島で成立した暦。 >>283
仕様変更ですね。規模見積もりますわ。
で終わりだろ。 >>283
文句言ったところで天下りしてきたおまえの元上司が出てくるだけだよ。 うちの会社のシステム、新元号対応に70年かかるとの報告あった。 特定の宗教に依拠しない世界標準歴を新たに定めるべき >>728
役所がシステムの発注する時に
「元号で計算をする」なんて馬鹿な仕様書にしてるんじゃないか？
未だに通信仕様に「アナログ伝送」を指定してくるし。 西暦はその発祥も宗教だが
そもそも今に到っても
「2000年だ～、世紀末だ～、ミレニアムだ～」という
語られ方の空気感も
ものすごく宗教的なわけよ。
ちっとも近代合理主義にそぐわない >>735
1年前までPC98が稼働してたのは確認した >>736
西洋の近代合理主義の思想的基盤にはキリスト教が存在してるんだけど。 >>735
役所関係は元号使ってる
あと古い体質の業界
データ上ではデート型で持たせてるが
表示プログラムだの帳票印刷関連回収が面倒 >>740
さすがに、役所のシステムに関しては改修は不用だよ。
テストがウザいだけ。 結局、開発したSEが想定できなかった糞と言うことで >>727
レコード長にキツイ制約がある一例として出しただけだよ？
他にも、スタンドアロンBASICのレコード長＝256や
文字列長の255バイト制限とかな >>735
どこの役所か知らんけど、警察とか自衛隊、
公安、裁判所、検察、なんかだと
アナログの方が良いんだろうね
デジタルだとコピーが出来てしまうのに対して
アナログ伝送は完璧なコピーができないので
「確実に送信された」という証拠になるのと
アナログ伝送は光の速度で届くから圧倒的に早いらしい
デジタルの場合、AD変換で時間が僅かにかかるとか 国が元号データとか祝日データとかをWebで公開して
各システムは定期的にそれを取り込んで更新、みたいにできないのかね >>745
いくつか理由があるけど、
システムを複数の会社に分けて発注するから
データのやり取りに「アナログ伝送」を要求するらしい。
ちゃんとデータのフォーマットを統一してくれればデジタルでもいいんだけど、
役所の人間でその仕様書を書ける人間がいない。 30年前って言ったら16bitが32bitになって、コマンドでWindows立ち上げてた頃だから
「将来を見据えろ」とか言ってもそもそもの作りが違うので、ナンセンス。 バカが設計したんじゃなければ、どんなシステムでもアップデートやメンテナンスを想定して作る
だから、とても簡単な事だろ
和暦は変わる可能性がある
つまり、それを想定して後から追加できるように作ってるはずだからな
出来ないのはバカが作ったシステムなのだから、開発者や仕様決定に関わったクライアントに損賠賠償をしたら良い >>751
30年前って言ったらDOSやWindowsは基幹システムで使えるようなもんじゃなかったから関係ないんじゃ？ ■ このスレッドは過去ログ倉庫に格納されています
