【IT】2019年5月1日に新元号、NTTデータや日立は「対応難しくない」 ->画像>2枚

皇室会議で2019年5月1日に元号を改正することが決まったと、2017年12月1日に新聞各紙が報道した。2018年中に新元号が公表されるという。政府は2017年12月8日に正式に閣議決定する見通し。元号の改正に伴うシステム修正が必要となる。

　NTTデータは「元号改正による修正は限定的」（同社広報）とみる。システム内部で保持する西暦日付を和暦日付に変更するテーブルの修正が必要とする。

　日立製作所は「平成から新元号への対応は比較的容易」（同社広報）と話す。新元号の公表から元号改正までの時期に余裕があるため、変更作業を計画的に実施できるほか、昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。
http://itpro.nikkeibp.co.jp/atcl/news/17/120102783/

言う以上にさらに簡単かもな。
無駄な工数増やしそう

西暦に統一。こんな税金に巣食う糞どもに仕事を出さなくていい。

これからは西暦に完全統一！

だってやるの俺らじゃねーし

でも関わる人達にはGW無いんだろうね
当然代休も

基本的に元号使うシステムは既に改元に対応してるだろ
後は問題がないかを再検証するくらいだけど、今回はそれも事前にスケジュール組めるだろうし

元号使うのって役所と産経新聞ぐらい

この２つの組織は馬鹿みたいに経費を使うだろうな

最近のシステムなら定義ファイルに追記する運用の範囲内
プログラムの改修もアップデートも要らない

アルティメット日本元年

役所関係の帳票は影響あるな。

今は、1890年あたりをスタートしたものになってるから、対応は簡単だぞ。

>>8
漢字３文字にされたら、ほとんど対応できないと思うぞ。

内部的に西暦でカウントして和暦で表示してるだけじゃないのこういうの

京都の例の案件どうするんだろうな

>>13
大昔のシステムだと内部的に昭和でカウントしてたり・・
2025年に昭和100年問題が起きる恐れ

ワイ「元号なんてガラパゴス表記は廃止して西暦に統一しろ！そのほうが合理的やろ？」
ネトウヨ「元号が嫌なら日本からデテケー！元号には歴史ガー！伝統ガー！文化ガー！」
ワイ「やれやれ…困ったもんだ」

＞＞１２
３文字になることは絶対にないから心配無用

>>3
それが一番いい効率的にも
でもTwitterで役所関係でも元号のところに横線入れて西暦で提出してもOKだってさ
多分、外国人がそれやりだして日本人もOKになったと思う

>>3
皇紀がある

金儲けのネタｗ

1月1日でいいのに、なんでアベは中途半端な時期にしたのか！
新年の儀を現皇太子である、新天皇に引き継げばいいだろう。
　

そもそも平成に変わった経験とか2000年問題の大騒ぎもあるし、
年号の変更を考慮していない糞システムなんか作る方も頼む方も認めないわ

今日免許証を更新にいったけど
次は平成何年までってなってるわ

保守派だし元号は大切だとは思うけど、パスポートと同じように車の免許だけは西暦にしたほうがいい

でも請求はしっかりと

>>21
GWを10連休にした方が庶民は喜ぶだろうという配慮かららしいよ
正直6月に休み欲しいところ

昭和平成が扱えてんだから次も問題ない。

ノウハウとか古いホスト以外ねーだろと。30年前なんてどんな対応したかわからないし
その時新人レベルの要員しか今は残ってないっての。日立の広報はどんなノウハウなのか説明してみろよとw
まあ対応時間はあるからあわてる必要はないけど。

問題は大半の新しいシステムは2000年以降に作られてるから、帳票やDBがらみの影響が大きいわな。
特に役所と医療・教育機関と本邦向けの金融機関あたりか。
実装的には、平成とか元号をソースコード内ベタ書きで持たせてるところかな。COBOLやVBA、Javaなんか特に。ビットで持たせて拡張出来ないなら面倒かもね。
あとDBのカラムに元号持たせて平成しか考慮してない日付情報とか。ほっとくとキー重複するだろうからマスタ拡張とか入出力変更はあるだろな。
それと手書帳票向けの明大昭平の欄か。明治消すのかな？
最後にOSやOffice製品等アプリのアップデートかな。Windows10対応など最新にしてれば難なくやれるかね。

別途、4/30と5/1が特別休日になるかもしれないからおまけで対応ってところか。

>>12
三文字にしますなんて言っても騒ぎになって撤回するから
それでも通ったらしょうがない
そんな事まで考慮してシステム作るのは金の無駄

>>12
過去に4文字元号もあったし、
そこまで考慮できないならSE失格

文字数もだけどJIS第一、第二水準にない漢字使った元号になったらえらいことになりそ

いっそ絵文字にUnicode対応を推進するべき

JISとかは大丈夫でしょ。庶民が馴染みのない漢字をこの時代に選ぶようなことはしないよ。
まあ合字とかもあるけどUnicodeなどその辺の対応は各団体やICUなどでやるプロセスはすでに組まれてるからユーザレベルじゃ気にしなくていいと思うけどね。
それから漏れたマニアックなライブラリ使ってるとかなら面倒だけど。

>>30
官公庁から二文字までで良いと言われた
当然三文字設定しても動くけどね、レイアウトの保証はせんが

元号は、辻元にすればいい
ネトウヨが元号使うのは、やめようと
言い出すはずだ

>>24
あれは年号と西暦併記した方が良いね

いちいちこんな事発表しないといけないほど一般人の情報リテラシーは低いのか
改元で誤作動おこすんじゃね？とか本気で考える奴おるのか

なんで元号など使うんだろ？
こんな面倒なものに固執してるの日本ぐらいじゃない？
北朝鮮でも西暦だし。

昭和→平成の時に全部やった
共通ルーチンのテーブルを変更するだけ
共通ルーチンはダイナミックリンクだから個々のアプリケーションは変更の必要は無い
内部データは西暦４桁
和暦表示が必要なときは日付をセットして共通ルーチンを呼び出し
返って来た元号と年を使うので全く変更の必要は無い

>>37
昭和→平成のときはコンピュータ史上初めてのことだったんで色々あった
まだ内部データで和暦のシステムが残ってたし
でもその時にきれいに>>39の対応をやった

役所銀行関係は実にめんどくさい…

銀行の通帳を見ると、日付が和暦なんだよね
しかも、「平成」を書かずに、29.12. 3のように数字だけ

新年号に変わると、年の桁は1になるんだろうけど、
いろいろとわかりにくそう

「元号が変わるからそれに対処する」
言葉で言うとそれだけのことだけど
実際には、いろいろな場所にいろいろな形で現れるだろうから
地味にいろいろ大変そう。
入力欄が明治大正昭和平成ってなってるなら、それを変えなきゃいけない
平成３２年という入力も以前なら妥当だったが、それが妥当ではなくなる
それをどう処理するかとか。
もちろん元号変更を想定して、あらかじめ準備している部分は多いんだろうけど。

>>39
ところがテーブル変えてもなぜか変わらない所があるのがIT土方クオリティｗ

日付の大小比較ロジックを直さなきゃいけない所はどこかにありそう

大穴で新元号が「null」になると引っかかるところはあるだろうかという思考実験

>>12
アフォ？漢字二文字と法律で決まってるんだけど…

>>1
　彡⌒ ヾ
　(　＾ω＾)ほんと馬鹿らしいわ

　彡⌒ ヾ
　(　＾ω＾)もう西暦しか使われていないだろ

　彡⌒ ヾ
　(　＾ω＾)行政は西暦に固定しろや、バカども

　彡⌒ ヾ
　(　＾ω＾)中国ですら西暦が多いんだぞ

西暦より皇紀のほうが合理的
約600年分をワザワザ紀元前って理る必要ないからな

当たり前だ
３０年前より進歩してなくてどうする

8bit機があちこちで現役だった時代と比べたらね

というか、すでに対策してるでしょ。
対策してなかったら仕事してないとしか。

俺が納品したシステムに元号使ってるのはないな
特需関係なしつまらん

和暦の処理テーブルにデータ追加するだけだからな

>>46
法律ではそうは決まっていない。内規のような位置付けの
元号制定実務要綱で漢字二文字とされている。

漢字2文字
アルファベットの略号が現在と重ならないようにする

この2点の暗黙の了解が守らられないとヤバいって事だな。

前回は元年が数日しか無かったが今回はそこそこあるのが違うかな。

退位を待たずに崩御の可能性もないわけではない。

元号を使っているのって「お役所」くらいじゃね？？？

「平成50年度までに」って表現は使えなくなったな

>>57
お役所と全く関係なく仕事してる人って、いないんじゃないか

>>57
神社仏閣。

>>58
元々平成が50年まで続くと思ってる人、ほとんどいないだろ。

>>21
宮内庁がおのれらの怠慢を棚に上げて抵抗したらしい。
皇太子のリハーサルが間に合わないんだろう。

>>62
皇室の年始祝賀行事なんかとの兼ね合いで嫌ったらしいよ
いずれにせよそこは宮内庁側の意向が強く出てるところだから政権側の問題ではないね

>>44
変わらないところがあるなら昭和から平成にも変わってない

明日、突然死したら、いつから新元号？

>>55
現実問題としてはSとH、あとは精々Tを使わなければ問題ないと思うよ

平成になる時に新しい年号に変わっても大丈夫なように手を加えてるから
テーブル追加してテストしたら終わりなんだが……
失礼な話だが、昭和に比べて平成が短くなるのは想定内だし。

>>67
アルティメット日本元年
に決まりました!

え、年号テーブルで管理するだけじゃん
１レコード追加でいっちょ上がり！で何百万も取るのかねｗ

年号じゃないや元号だｗ

>>69
動くかどうか分かりませんテスト工数寄越せとか言ったら当時に遡って賠償請求だわ。

難しいって言ってくれよ

2000年問題「元号くらいで騒ぐなよｗ」

実際、いきなり変わるより良かった

なんで？昭和から平成のときに
やったでしょ？
漢字入力かえるだけなのに

西暦2ケタ表記から4ケタになった2000年問題の時はパニックになると騒いだもんだよなｗ
99から00になってシステムがダウンするとかなんとかで。

西暦でええやん

やっぱり役所関係が元号まみれだわな

公的書類は西暦に統一すべき
元号は干支と同様の扱いで、カレンダーに付属情報として追記するくらいでいいと思う

二文字飽きたから四文字行こうぜ!

四文字にして、あちこち阿鼻叫喚の様になれば面白いのに。

「元年」じゃなくて「一年」って出力されていいんだろうか。
元年表記にするなら、結構面倒だな

前に直し忘れ、数十年に一度しか動かないﾓｼﾞｭｰﾙとかｗ

そもそもITで日付計算が関わる分野に和暦は不要だろ

>>80
　彡⌒ ヾ
　(　＾ω＾)三文字ぢゃダメなのか？

4月1日に変更にしろよ、面倒だろ
一番いいのは、西暦のみにすることだけどな

ってか良い加減に紙のカレンダーなんて廃止すれば？
いつまで紙切れを売ってるの。

「でも安値でやるとは言ってない」

お前らは下請けに投げるだけだからな
要件定義は超簡単だしな

>>61
亀レスだが、極端に書いただけで
平成32年度完成、とかが使えないって意図はわかってくれたかな

西暦が5桁になったらどうすんの？

>>66
いやいやM使われたら誕生日で詰む

>>91
8000年前の建造物なんか何一つ残ってないから
も使わんだろ

>>86
誕生日による学年分け計算は4月2日で区切るから逆にややこしいぞ

>>75
MTSH +数字2桁で処理してるシステムもある

現行運用中の製品で、元号変換対応をあらかじめ設定して無いとか
それこそアホか馬鹿かと罵倒していいレベルだろｗ

>>57
主に納税とかで役所への申請が絡むシステムは民間でも元号多い
給与計算の中の、健康保険、厚生年金、労働保険、介護保険、年末調整、
固定資産税に関係する、固定資産管理、設備管理、
印紙税、消費税関連、連結納税管理システムとか

普通はこの手のことは、
定義ファイルかDBで持ってるだろう

>>96
そもそもユーザー企業の情シスが、予算がないからと言って元号変換対応費用なんか払ってくれない
だから毎回金払うことになる

>>98
サブシステムが200ぐらいある大企業の基幹系だと定義ファイルやDBも200ぐらいあったりするんだよな

仮に新元号の省略が��Ｈ�≠ﾅも大丈夫？

>>101
それはやばい
内部的にはIとかで保持しておいてプログラムごとに変換して使うしかない

どうせ問題が起きるｗ

対応すげぇ難しいのに上の方は能天気だ

>>102
つまりいつかは難局をむかえるね

アルファベットは26あっても、ＰとかＱとか使えないもんな

>>105
その次の元号になるころには俺は定年だろうから問題ない

うちはヤバイよ。
平成に出来たシステムなのに元号がマスタで管理されてない。
javaもCもシェルもハードコーディングのオンパレードでどうしようもない。
元号記号がMTSHもあるし1234もあるし、和暦2桁だけのパターンもある。

>>108
全く問題ない
他所も同じようなものだから

>>105
未だって古い元号ではなんかかしら頭文字がダブってると思うけど
別に問題無いよね
ある程度離れたらもう混同の心配もないし、処理的にはどうとでも出来るでしょ
そもそも古い年号は扱わないだろうし

平成になる時に候補に挙がった元号

修文　しゅうぶん
正化　せいか
永安　えいあん
乾徳　かんとく
昭徳　しょうとく
天興　てんこう
興化　こうか・きょうか
光文　こうぶん

>>111
永安しかないわな

>>110
現行の法律ができたのが明治以後だから契約管理系だと少なくとも明治はずっと必要
例えば明治に取得した資産は明治の取得日がずっと残る
大量の不動産を抱えてる老舗大企業だと
固定資産を全て処分しない限り明治がシステムからなくなることはないんだな

民間は西暦にした

ええ、ええ、ちょちょっとやればできますよｗ

下請けに丸投げするだけのカンタンなお仕事です

>>108
わろた

>>101
Hにはしないよ

昭和から平成、2000年問題
コンピュータが普及してこれで3度目
対応できなきゃただの馬鹿

金がいくらかかるかは言ってない。
難しくないが金は猛烈にかかるよ

ソースに書いてある名前が劉とか王とか李とか徐とかばっかだから仕方ないよね。
中国人に時限爆弾を仕掛けられて気付かなかった日本人が悪いのだから。

元号なし和暦2桁のシステムをみたことがあるがどうするんやろか

つーか次期天皇皇后ってどうなるのよ。
天皇制も元号も終了でいいよ。

長男相続は差別。差別をなくそう！

>>26
年よりばっかりの国、仕事も介護とか看護とか、土日祝日関係ない仕事ばっかり。
連休は誰のために作るのか。

>>119
だからユーザ企業の情シスがバカなんですよ
毎回最小限の金しか出さないから

>>122
2025年＝昭和A0年、2026年＝昭和A1年で
あと260年持つな

>>126
古いシステムだと数字部分が2進化10進数だったりするしな…

>>91
西暦10000年問題への対応策なら検討されてるよ

http://www.ietf.org/rfc/rfc2550.txt

>>128
西暦100K問題も考えないと

そりゃ元請けはそういうわ。現場は大変。

現場は無茶な要求を全て受けなければいい。

>>131
営業が勝手に受けるからどうしようもない。

これを機にシステム内はもとより入出力全てにおいて元号を撤廃すべきだよな

>>133
現場から情シス部門を説得してくれ
たぶん見積もり10倍超えるけど

番号体型に元号なしの年を使っているところは面倒だな

銀行系のデータは和暦でしかも元号の情報がない
どこかの銀行で業務がストップすることがありそう

>>51
今回

まあ日本が元号対応で立ち止まっている間に中国や韓国、その他新興国がどんどん先に進んでいくんだが。

まさかのキラキラ元号で対応できずに1億ジンバブエドル

ITなら2038年問題あるぞ
32ビットOSが確実に誤動作する

まあデータや日立なんて秀才の集まりだからな
彼らが言うんだったら間違いないな

>>16
むしろ皇紀を復活してほしい

>>142
皇紀は廃止されていないけど。誰も使わないだけで。
明治〜戦前だって、皇紀なんて常用していた組織なんか
なかったのだし。

時々こういうドタバタがあった方が人心が改まっていいやん。長生きの秘訣みたいなものだ。
神社だって遷宮の時は伊勢みたいにがっちり新しくした方がいい。

日本に元号と言うシステムがあり、しかも今上天皇陛下の即位年齢を考えれば、平成の次やその次の改元は６４年続いた昭和と違ってそう遠くないのは自明だったはず。
もし改元に対応しないシステムが稼働してるとすれば、それは怠慢と言っていい。

とは言え、「簡単に出来ます。」とエラいさんがうそぶいても、現場の方は顔面蒼白なのは推して知るべきだろうけどなｗ

>>144
定期的に行われる伊勢神宮の遷宮は、宮大工の育成のための貴重な機会として役立ってる。
改元も２０年おきに定期的に発生するならがっちり対応も出来るんだろうけどな。

>>144
こうやって付加価値ゼロの作業に大量のITエンジニアが投入されてるから
日本にはGoogleもFacebookもアリババもテンセントも生まれないんだよな

　


今の天皇が退位後に死んだら休みになるの？


　

>>145
悪いのは予算をケチる情シスであってSIerではない

>>136
いわゆる昭和100年問題だな
2025年より前に直すチャンスができてよかった

>>148
「崩御」と言う日本語を憶えような。

>>149
大したことない機能に糞みたいな見積もり出すSIerが悪いんだろ
大体からして日本のソフト屋なんてキーボード叩けるだけの能無しの集まりだろ

何も難しくないよ
だって内部はもう西暦で処理してるし

はっきり言えないけど、最初から準備は済ませてるだろ

新元号は「安栄」です。
安倍がさかえるという意味です。

>>140
２０３８年問題とか、そういうのって予め、
わざと一部のシステムや同型のあいてるシステムの時間を２０３８年まで進めて
どういう影響出るかテストしてるだろ。
基本的に内部時計のカウントを古いタイプは１９７０年まで戻して、
そこに結果表示時に６８年分をOS側がプラスすればいいだけのような気もするが

元号変更で大騒ぎするSIerは無能だから相手にしなくていいよ
とっくの昔に対応済ませてるのが普通
日立は口だけだから実は対応してませんが大量にあるだろうが

>>152
金払いたくないんならユーザー様が自分でやりゃいい

もう元号要らない
有り難みも無いしメリットも無い
西暦だけでいい

>>158
最近は自グループでシステム屋抱えてるところが多いよ
もう金ばっかりとって無能な大手には頼まんわ

　


難しくないのは当たり前。
天皇は定期的に入れ替わるんだから。
こんなの最初から考慮してるだろ。
NTTデータや日立だけじゃなく、NECや富士通もだろ。

ちなみに、
2000年問題は、西暦の記録を19xxのxxの2桁だけでやってたから起きた問題。
元号とは無関係。


　

とっくに元号テーブル作ってあるだろ
カネ取るつもりか

元号を使っているシステムなんてあまりないだろうからな

　


>>163

いくらでもあるだろう。特に役所。

ちなみに
エクセルだって和暦はある。
元号変わったらアップデートがあるだろうな。


　

元号マスタにデータ登録するだけでないの

>>82
それ
基本は元年と表記する必要がある
税金の通知とかは1年なんて表記したら「誤りだから払わん」とゴネる奴がでてくる

1年半あれば十分でしょ。

前回は12月入ってから
「年末アヤシイから準備するように」
とお上からお達しがあって、越年。

>>155
新年号は「晋安」です
どこかの鐘と同じように呪詛します

>>161
前回の2000年対応は、例えば西暦の下2桁が49以下なら20ｘｘ年と表記
50以上なら19ｘｘ年と表記みたいな対応なんだよね
だから、ロジックを変えないままかつメインフレームを使い続けているなら
30年もしたら問題が出るんじゃないかと思う

2000年問題のときについでに修正してるんだろ

つか、いい加減、西暦だけに統一して欲しい。

時間の計算は西暦でされてる
元号を使うのは元号を表示する場所だけ

新元号のイニシャル、A,I,U,E,O,K,N,Y,R,Wどれが来るんだろうな

seirekiが来てほしい

大企業「簡単です！」(下請けにやらせます！)

いくら対応が簡単とは言え時間と費用がそれなりにかかってるんだからなくした方がいい
人間が和暦から西暦に変換して入力してすぐにフロント内部で西暦に変換するって無駄にも程がある

>>176
間違えた。
人間が和暦から西暦に、じゃなくて
人間が西暦から和暦に

いいこと思いついた
新元号は「二〇一八足す」

誕生日が面倒だよなぁ 平成30年のひとと新暦元年の人が混在するようになる。
平成元年の時は一週間くらいだったので
ほとんど対応不要だったけど、けど今回は対応必要なのかなぁ。

天皇と同じように、和暦も象徴として皇室行事だけで使用するようにすべき。

税金で作るシステムは和暦を禁止してほしいよ。また次も改修コストかけるんたろ？

一番良かったのは、退位は予定通りで、改元は2021年1月1日から実施にすることだった
改元と退位が一致しないことなんて前例があったんだし

そりゃ丸投げする側はそう言うだろうよ

今、ネットでダウンロード出来るし、基本西暦でプログラム組んで、表示だけ和暦だろうし。

>>181
今、普通に西暦でプログラムしてるだろ。（笑）
表示だけ和暦でしょ。

>>182
その前に崩御されるかもしれんしな。

日本政府のお得意技。

>>180
そうだよな。
江戸の時みたいにコロコロ変えられてもな。

元号マスターは更新してテストで良いとして、帳票系でレイアウト変更必要なのとかしんどいかもな
M・T・S・Hで四角く組んでるとこに、新元号入れたら、元号欄と同じ行の項目のら最大出力文字数を縮めないといけなくなるかもしれん
マークシート帳票とかも
頑張れ〜

役所よりカレンダー業界の方がやばいだろ。
５月以降は元号を空欄か自分で書く仕様にするのか？
天皇誕生日や平成上皇の記念日変わるけど、５月にまた新しいの出すのか？？

新元号は
「和暦」

>>161
３０年もメインフレームで、システム更新しない旧システムのままは普通じゃない
システム更新時に次の元号更新用の対応をしてなけば、SIer 共にユーザー自身の自己責任でしょうね

こんな事と言うとアレだが平成の次も長く続くとは限らんからな
すぐ改元とか元号廃止とかありうる

>>188
今現在で明治生まれは2人だけ。
大正生まれも90歳こえてる

>>5
年号の関数を代入するだけだぞ

パッチ当てるだけだから、顧客にさせてもいいレベル

>>30
その場合は過去と同じで頭に『天平』ってつくんだから〜
改修するのは二文字だから〜

天平明治
天平大正
天平昭和
天平平成

>>17
あ、これヤバい奴だ

>>188
出力帳票なら、１つの欄に複数の元号表示なんてないし、
入力伝票なら、通常は印刷屋に発注するものだからシステムに関係ない
印刷屋なら、レイアウト変更があったとしても、しんどいなんて事はないでしょ
システムで怖いのは、まさかの元号３文字以上だけど、それは政府もやらないかと

>>192
次も50代で即位して崩御にせよ譲位にせよ80代で代替わりだろうからやはり30年、
その次は継承順位で考えると秋篠宮天皇（仮名）時代が5年〜10年、その次が50年前後か。

>>189
2回売れるからむしろ助かるじゃん

というのは置いておいて流石に一年前くらいには公表するだろ

>>12
外字とかもされたら大変だな。外字テーブルメンテは手順書化されてないのだ。

>>15
俺が入社した時の上司が「平成36年がヤベー」って言ってた。

>>29
俺、そこまで考慮してシステム作ったら、金の無駄だって言われたけど、そいつを釧路に左遷してやったわw

>>21
新年の儀と被るのを宮内庁が断ったらしい

>>12
横文字にしようぜw

エクセルの土方作業で死ぬのだ

>>194
だがな、SIer張り付けたがるユーザも多くてな。

自分で作らないポジションの奴らに取材するなよ。

大手は改元対応自体を組んでるはず

安いベンチャーとかで
目先の問題をデスマーチで乗り切ってるようなとこは危ない

つくづく思うのだが、
なぜ崩御とかで急を要するのでもないのに、西暦のキリのいいとこと
合わせなかったんだ？
もう１年、皇太子が天皇陛下の名代で乗り切ればよかったじゃないか？
無駄な予算増やしすぎ、使いすぎ。

>>210
退位したら自決するよ
そういう御方だもの

>>210皇室会議に左翼が紛れ込んでいて、
皆に迷惑な皇族を印象づけるため？

>>57
政府、銀行、マスコミ(産経、読売、NHK)、役所、２０００年対応の時よりやばいＭ

>>194
元号変わるので一番困るのは
元号変わった後でも、旧元号で書類作成をしなきゃならん事務
に対する対応だよ
できんことはないが、個別に対応するとめんどくさい作業が結構発生する

安恵元年

創安元年

大創元年

自安元年

愛雅元年

フラグ立てすぎだろwww

>>190
「西暦」のほうがいい

人間いつかは死ぬ。
それは今日かも知れない。
崩御が今日なら改元は明日。

安倍チョン改革、奴隷国元年

銀行が和暦はヤバイね
金融パニックになるかも

>>14
最初からくんだ方が安く上がるんじゃないのか？

銀行はまだ和暦なのか？？

IT土方「年号変更機能はあらかじめ用意しといたし大した影響ないだろ」
客「なんかあったとき困るからGWは待機な」

>>214
テーブル参照刺せるんじゃあ、駄目なのか？
事前に想定してないと？

>>223
GW明け
ウイルスバスターが日本中のパソコンを起動不可にして阿鼻叫喚に陥れたのは遠い昔なんだな……

amaちゃんだ‏ 
@tokaiama
今
23 分前


その他
NHK受信料の何が問題か？
現在、民法改正要項になっている「契約の自由」のなかで国家権力による強制契約はありえないことを示す条文になっている
そもそも民法90条＝公序良俗則では、NHK契約の強制は認められない
NHK契約の憲法上民法上の根拠は一つも存在しない

こんなので難しいとか言われたら仰天して椅子から転げ落ちちゃうよね

役所とかややこしそうなのは分かるけど
昭和→平成の時はどうしたんだよ
平成以降に開発したなら対応してるだろうし

M T S Hを外した年号にしなきゃならんのだろうね。

>>228
昭和65年表記で暫定対応し、修正は昭和のとこにゴム印押して対応

当時はインターネットなんか無かったからネット対応云々は考えなくてよかった

>>230
間違えた昭和64年だわ

>>230
これな。

>>225
数年前にもWindows7がWindowsアップデートの糞内容のせいで起動不可になりましたやんw
な〜んにもなかったのにさw

>>214
旧元号というか5月1日以降に4月1日〜4月30日付けでの処理と文書発行しなきゃならん処理だな


あれ?平成31年4月12日付文書で「期限:○○元年5月23日」て書くのはありだっけ?

西暦に統一でいいよ

そういってシステムが停まるんだよなぁ
しかも凄く小さな人的ミスで2，3日原因不明ｗ

>>235
免許証に西暦も書いてホシイナー

>>1
平成終わるなら平成30年予定の増税は白紙に戻るんだ

>>111
安倍政権よえいえんに

でも金は取ります。

改修に数百万取りますって言ったら殴られるレベルだろ。
出力テストはするだろうけど、基本パラメーター変更で済むレベル

そんなに甘くねーよ

>>241
そう言いつつ事前に全部の帳票の出力の検証しろとか言い出すんだよなあ
設定変更の作業工数だってただじゃないんだし自分たちで出来ないんだったらおとなしく金くらい出せよ

>>241
そんなに安くないよ。
システムの規模にもよるけど、一桁違うのもザラ。

なんでスケジュール引くだけの人に訊いてるの？

日程が決まってるだけマシだろ
ごちゃごちゃ言ってんじゃねーよ

>>241
改修そのものよりも、テストだのドキュメント変更だので改修の100倍の手間がかかる。

平成は、年号がItaniumなんて変わった時代だった

>>166
やはりだめですかね
バッチ系の帳票はオーバーレイから修正が必要になりそうだな

退位、元号替え、朝鮮核or空爆戦争、どれが先に来るかな。

>>15
そんなのあるの？

最近のシステムなら対応してて当然！みたいな事言う奴が多いけど、現場からすると一からスクラッチしたシステムならともかく過去のシステムを更改
してきたようなシステムだと対向システム側に合わせる都合とかそもそも既存の部分は既存の通りに動くようにしろとか余計なところは触るなとか
そういう積み重ねの結果過去なクソソースが残ってる事が多くて、それを今の運用保守のせいにされても困るというか…

2000年問題の時に合わせて修正している
出来ていないのは無能な証拠

昭和の時代から使われてるシステムってのはもう無いなぁ
そもそも当時パソコン使ってないし

>>254
銀行とか京都市とか

変換サブプログラムを改造しておけばokだろ
カレンダーテーブルに何十年分の西暦と和暦が入っているシステムならSQL一発流せば完了

>>253
それは2000年問題の時にそんな対応仕込む金を出してくれた客が偉いだけだろ
逆に金貰ってないのに対応したなら金もらうチャンスを溝に捨ててるわけで

>>257
いやいや、金を出さずに対応を迫るのは、客の常套手段だぞ。

瑕疵担保で費用は請負持ちで派遣奴隷が24/365労働で直すので「対応は難しくない」ですよ

>>160
結局自分とこでまともなの作らずに外注運用がほとんどやん

新元号対応のついでにやってもらおうと、別要件をロハで入れようとする客に注意だな。

>>254
昭和の時代末期はとっくにコンピューターが使われだしとるよ

昭和の終わりに改元対策やってた一人だが
今時そんなのに慌ててる奴はアホだけだろうよ

>>258
それに押し込まれる営業が無能なだけだろう

5月1日は水俣病公式確認の日でもあるななので朝日新聞潰したいのは自然だろう

平成の次のことまで考えて対応しますか？
動的にマスター管理するように仕様変更するので、見積は高くなりますが
うーん、だったら暫定対応でいいや、平成もしばらく続くだろうし
そん時はもう定年になってるしな、ガハハ
↑
現実はこれだろう

和暦管理は無駄
これを機に行政のドキュメント全て西暦管理するように指導しろ

>>267
無駄があってもいいじゃないか

FX（外国為替証拠金取引）のEA(自動売買ツール)とサインツールを開発・公開しております。
興味がありましたら見てみてください。
https://goo.gl/4F8d3o

>>255
そういうところはとっくの昔に対応した

>>189
カレンダーは、そろそろ１９年分は最終稿らしいからＯＵＴ

>>198
元号は漢字２文字と元号法で定めているようだ。

>>257
その発言が私は無能で馬鹿ですってのと同義な

新しい年号を西暦にして2019年からスタートすれば無問題

>>1
そりゃそうだろ
大儲けの注文がもらえるんだから

Windowsupdateはどうなるんだろう。

昭和から平成になるときに対策してるだろ

>>277
ヒント：トラッドな大規模システムの更改は５年毎。

>>116
>>183
書くことが無くなってしまったｗ

>>278
現行踏襲だろ！！！１１

新元号はヱゐゔぁ。