【改元】新元号の令和発表、改元で“コンピューター誤作動の恐れ” CNNが指摘
■ このスレッドは過去ログ倉庫に格納されています
新元号の発表に伴って海外メディアからは、日本がコンピューターの誤作動の問題に直面する恐れがあるという指摘がされています。
アメリカCNNは新元号の発表について速報で伝えるとともに、元号の変更は時代の変化の象徴であると同時に、日本が技術的に差し迫った課題に直面すると解説しています。かつて世界中でコンピューターが誤作動する可能性が懸念された西暦2000年問題を引き合いに、日本のコンピュータープログラムの多くが元号と西暦を両方用いていることで、同じ問題が起こる恐れがあると指摘しています。
2019年4月1日 14時27分
テレ朝news
http://news.livedoor.com/article/detail/16249965/ >>1
マイクロソフトのアップデートにバグが出ると予想してるんだなw
先月あたりのアップデートで平成の文字バグあったしw 2000年問題なんてマスコミが大騒ぎしただけで何も起きなかったわ 未だ、BASICでプログラムしてると思ってるんだ。 >>1
内部時計を持っているのに、今さら誤動作は無いわ
テクノロジーのことを何も知らん記者が書いた記事だな 世界が日本の元号というのに注目したのはこれが初めてだろう。 出力の時だけだからなあ。
2023問題のほうが深刻だわ。 飛行機が墜落して原発が爆発して富士山が噴火するのですか? まぁ誤動作というより非対応は出てくるだろうけどそれは仕方ないよな >>1
>例和!の時代は!!
↓【マジ世界平和】!!!
マジ天才↓
↓【【マジ】】
↓↓『戦争をなくして世界を豊かにする方法!』↓↓↓↓
(人類社会のルール変更)(世界最高税率統一)
http://www.kakiko.info/bbs4/index.cgi?mode=view&no=10099&p=8
小説カキコ掲示板 2000年問題w銀行がぁとか不安煽りまくってましたなぁw 元号なんてただの表記だからね
そも問題が起こるってんなら明治大正昭和平成って混在してる現時点で出てなきゃおかしいだろ
まったくどこの商業マスゴミも、大変だ〜〜〜大変だ〜〜〜と騒ぐのがお好きなようで
2000年問題と同列で論じるとは噴飯もの、2000年当時飛行機が墜落するとか
原発で大きな事故とか、目いっぱい騒いだのにまだこりないのか いまどき内部的には西暦使ってるだろ
さすがに問題ないと思うが >>5
お前・・・・
あの事件の裏で何人亡くなったことか・・・ 今回は日本のパヨクですら原発が爆発するとは騒がなかったろ? うちは銀行から来る糞データ以外全部西暦になってるから平気
銀行の糞データ以外はね!! そんな心配より、Oracleはうるう秒に対応しろよ アメリカの豚と一緒にするなやw
平成、2000年とこなしてるんやでw
頭悪すぎのアメリカとは違うのだよ windowsだったらパッチで終わりだし
基幹系でもいまどき、元号をテーブル化してないとかないと思うけどな >>20
あと4週間あるんだから
4週間後におろせ >>27
文久の時は停電になったりして大変だったよ。 年中行事なので元号云々は要因の一つに過ぎない。
紀元で統一しても同じ問題を繰り返し起こすのがIT土方。
令和の英訳はelegant hermonyが真意に近い。 >>10
そうか?システム開発の人が元号を変えるのは意外に手間隙がかかり難しいというようなことを言っていたよ。 10日も連休になるんだから、食いもんは保存食を集めるんだぞ この手のネタは、2038年まで気にする事はないと思われ。 もう年末から和暦使ってたクソシステムは
西暦対応に改修済みだよ ノストラダムスの恐怖の大王がどうのこうのって
2000年問題の事だったよね 大概のシステムは元号が変わっても
元号データ突っ込めばそれで済むように
準備されてるだろう
ソースを"平成"とかでgrepしたらヒットするような
とこのは知らんw 来月までにデグレないように
頑張れ >>31
データを追加するだけなのに
保守料5億です そう言えばハンコ屋が元号訂正印売りにかかってたけど俺ならExcelかWordで位置合わせして旧用紙プリンタにぶっこんで上書き印刷するわ
なんで一個一個ハンコつかなきゃいかんのか どーでもいいが
西暦やめて
日本の元号を標準にしりゃーいいがな
アメさん 平成31年と令和元年はシンクロ同年月だと認識させれば大丈夫だろ。 ☓ 2000年問題
○ 本当にやばいのは2038年問題
現在殆どのコンピュータが32bitで実装している
unix時間がオーバフローする 表示用の値が変わるくらいで不具合も何もありえねえだろ いきなり変わる訳じゃなく、いつ変わるか言われてるんだから
その準備出来てない企業がどうかしてるわ 仕事を作ってやってるんだから
プログラマーは感謝しろよ
景気浮揚策にも最適な元号変更
これ文句を言ってる奴は売国奴 この程度で誤作動するようなら2度とその業者使うな
文字列でif文書いてるのか? >>60
その前にVisualBasic6の2023問題がある 今年になってだったかExcelで元号周りの修正に失敗してトラブルになってるよ
身近に起きないかもしれないが、どこかでは絶対に起きるよ >>16
ついにバレちゃうのか隠していた日本の核保有 >>1
そんときは、やっぱ、つ令和ってオチを言うだけ 2000年問題とやらも何も起きずに終わっただろ
いつものCNNのフェイクニュース > 【改元】新元号の令和発表、改元で“コンピューター誤作動の恐れ” CNNが指摘
基本..データベースや年関係のシステムは西暦で処理されてるはず。
元号は表面的な部分でしか使ってないはずだから問題はほとんど起きないはず。
もし改元で問題を起こすようなシステムを未だに使ってる所は..アホだわ。 官公庁は元号が基本
多分学校が一番大変
十年程前に元号変わるかもって噂が流れて秘密裏に対応した大手はセーフ
その時も直打ちで昭和平成判定してた糞コードがワラワラ出て来て笑ったわ >>67
2023年までにVisualBasicが問題ないくらい普及してない可能性が有るが
そういえば、昔よく作ってたやつはVisualBasic6だったわ >>1
ゼロファーストと同一視されても…
門外漢が動揺を誘うよろしくない記事だな
今さらわざとらしいわ こんなもん2K問題の頃からずっと言ってるだろ
アホかアメ公 まあ恐れは無いとはいえない罠
だけど2000年問題が起きなかった事を見ても
ほぼありえないといっていいだろ まぁ大手中堅はほぼ問題生じないだろ
オリジナルを作った中小は何かあるかもだが 平成になるときならともかく、元号が変わって誤作動とかどんなしょぼいとこが作ってるんだよ。
新しいシステムは内部的には西暦で処理して、元号との変換テーブルを持たせて表示のみ変換するのが普通 >>15
ウチで使ってる会計ソフトとかWin95頃に初版リリースのあと、10年ぐらい前に開発元がつぶれちゃってるというね 元号対応しなきゃならんと思ってたのに、レジストリに2019 05 01 令和_令_Reiwa_R とか追加するだけでよかったのね。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 紫衣事件でも、蛮人の非礼があったのか?
突然改元とか 自作ソフトはもう対応したで
内部データは西暦だから誤作動なんかないわ
あっても表示がおかしくなる程度 平成になった時だって、それなりに端末は普及してたし大きな混乱はなかった
2000年問題の時も馬鹿なマスコミは不安を煽りまくってたけど大したことはなかった
飛行機が墜落するとか原発が誤作動するとか言ってノストラダムス並みに扱ってたけどね
コンピュータよりも、ヒューマンエラーの方が怖いわ
911しかり、311の民主党政権しかり、人災が一番恐ろしい 既にコンピュータが存在する時代に、昭和から平成に切り替わりを経験してるんだから、
改元なんてまたあるって想定しておくものだろ。
どんな駄目プログラマが組んだんだよ。
まさか内部処理まで元号由来の数字を計算に盛り込んでないよな?
内部処理は西暦使って、表示だけ元号に変換すれば済むだけだろ。 そもそも誤動作が致命的な問題になるようなやつは2年近く余裕があったんだから
新元号を設定ファイルか何かに入力するだけでちゃんと動作するように改修してあるだろ
Windowsもそうなってる 昭和から平成で経験済みだから心配ないよ
よく使う文字コードだし
その後のシステムは、開発発注時から改元対応が仕様要件に入ってる >>1
アホかwww
Microsoftにしてもappleにしても和暦対応して無いだろwww EMP爆弾を造っている国が言及しても説得力皆無ですわw >>1
2000年問題の時も散々言われてたけど、何も無かったから問題ないよ GPSの週数ロールオーバーでもやっときなよ
平成の時に一応対応してるよ >>1
ていうか
世界中で日本の令和のニュースやってるじゃんよ
すげえ宣伝効果
デマ流した朝日新聞なんとか言えよ https://youtu.be/r7qbBtXULOQ
キスでいやいやさえなければハグらないみたいな言い方だな💏 >>83
それこそ2枚押すくらいなら書いたほうが早い >>106
対応してるよ
もちろん西暦の年を和暦の年に変換して表示できるってだけで
明治より前の太陰太陽暦を扱えるってわけじゃないけど ggge年m月d日
が、いつから「令和」に対応するかだな。
早くパッチ配信してくれ!!>MS 俺のAndroidは1970年1月1日なってる
Windowsカーネルは1601年01月01日じゃなかったけ プログラムなら数行変えるだけだろ
と言うか、もっと難しい仕様変更とかプログラマーは日常的にやってるだろ >>115
表示や印刷は元号だったりするでしょ
~←こんな文字もあるし エビデンスじゃ!エビデンスじゃ!
全世界のコボラー使って、和暦変換サブを
CALLしてるプログラム、全部動かせ! 西暦と和暦の変換ができなくてエラーになる、とかな。 >>53
データを追加?
そういう簡単なことではないよ。
例えばランタイムで走っていて元となったアプリの
和暦表示や変換機能を使っていれば、それを全部オリジナルに
書きかえなければならない。
自分で組んでいてもおなじ。
システム作るときは何年先も使うなんて思っていなかったり
するものさw それよりも2100年の閏年無いの対応してないのがあるかもね
きっちり4年に一度じゃないのでね2000年の時の閏年は
400年ぶりに閏年ある特異な年だったので普通に4年に一度で対応出来てるけどね 表示がバグる可能性はあるけどそれだけだ
内部で和暦で日付計算してるシステムなんてどんな骨董品だ >>118
それはアプリソフトが変換してるだけで、OS側は対応して無いでしょ 和暦で組まれたOSなんぞありゃしない。
平成31年5月1日とかの誤表示ならあるだろうw 海外からも遠回しに元号いらなくね?と言われてるだけじゃない
表だっていうとあれだから 対策できないとこは堕ちていくだけ。今回はみんなで渡ればとはならない。 >>36
余裕のハードコーディングやで
switchはだめいうからif elseにしといたわ COMMUNIST
NEWS
NETWORK
CRAZY
NEWS
NETWORK
LOL >>124
Y2Kの時に子供だった人?
プログラマーとか大勢その数年前からテストしたりして大変だったよ >>43
今時、元号をハードコーディングしてるバカはいねーよw ҿ
↑予約されているけどまだ見えない令和の特殊文字U+32FF >>135
というか未来の予定であれば普通に平成32年表記とかあり得る
俺の免許証の有効期限はそうだし、
国のプロジェクトの5カ年計画とかだってそうなってるだろう
平成31年5月以降だからといってただちに誤表示ではない 致命的なバグは無いだろうけど、細かなバグはおきる可能性高いよ
そんなきれいに整理されたシステムばかりじゃなのが現実
元号なんて効率の悪い仕組みを使ってる宿命だよ >>137
欧米の年月日や月日年や日月年てなってるのを統一して欲しいんですが 今日、馬鹿なシステム会社が新元号の設定で
2019/04/01から 令和、R
って指定しやがった
ほんとに馬鹿 令和の文字の16進数が特殊でプログラムに誤作動起こしまくりとかだろーな
政府はそこまで考えて元号も指定しなきゃならんのにこんなろくでもないのにキメやがって >>134
Windowsは.NET Frameworkが
macOSはCoreFoundation/Cocoaが変換APIを提供してるよ >>137
お前が無学だからヒジュラ暦とか知らないだけじゃない? >>1
不具合はみずほのATMの不具合が
十年以上続いてて日本人は慣れてる さすがに年の部分の頭にRがついていることに意味を持たせている
システムはないだろう
いや、あるかな? チャイナ製アプリが文字を間違えるぐらいは有るかもな >>145
言葉足りずにはだったかな?
元号が変わるのは日本の都合だからね(^^) むしろ公務員のヒューマンエラーのほうが心配
企業は利益に直結するけど公務員は怠慢だからな
入力表記を徹底しないとかありそう 2000年問題のとき病院勤務だったけど騒ぐだけ騒いで結局何の問題もなかったぞ >>137
なんだろう、主体性ないよな
イジメとかいいカモになってそう
マヌケすぎて >>152
マルチバイト文字がラベル以外に使われる時点でウンコプログラムなんですが >>151
そっか、そういうズバ抜けた馬鹿はいるのか >>166
あれは問題が表面化しないようにいろんな手を尽くしたからです。
もう一度同じことをやれと言われたらできるかどうかわかりません。 2000年問題の時のは昔のコンピューターとかの
メモリとかハード側が低用量で低速だったから
いろいろと少なく表記してプログラム小さくなるように書けが普通だった
なのでプログラム書いた人間しかわからない略し方とかもあったので困難を極めたよ
ハードが高性能な贅沢なコンピューターに代わってもソフトは互換でそのままとかあったからね
これからも言語側とかいろいろと問題が出るかもしれんけどそのつど対処していくよ で、Lなの? Rなの?
間違えるIT奴隷さん続出の予感 >>141
2000年問題と元号の問題とは意味が違うよな
そのへん分かってなさそう、このマヌケ >>105
平成の改元の時に間に合わせで対策して昭和100年問題が
懸念されているシステムが多いらしいよ 平成から30引けばいいから
計算はしやすいな
免許の更新とか 数字の頭につく可能性のある文字として、B,O,X を避けてくれたのは
良かった トランプに、フェイクニュース!って揶揄されてる
CNNが、まったく何言ってんだか…って感じ。www まぁランタイムの日付変換処理のアップデートがいるってのが面倒ではあるんだけどそんだけだな >>176
外人はさらに干支とか言われたら混乱してハゲそうだな CNNなんて、アメリカ版モリカケでさんざん騒いで、
司法判断ついたあとも屁理屈でトランプ叩いてるキチガイでしょ? ウチはソフト屋だけど一瞬で解決。
二重線の上部に令和と元のゴム印を作るよ。 >>158
なんかミスってるかも、これかな? ㋿
>>174
Rだって 皇紀2700年問題というのもあってな。
世の中には西暦2000年問題や改元問題を避けるためにあえて
内部表現を皇紀にしているという一見冗談のようなシステムが
現実に存在する。 内部はシステムタイムで処理して元号対応は表示部分と入力部分くらいだろうからそうそうないだろ 辞書登録せんといかんの
アップデートくんの
どっちだああああ >>178
一応ごまかすときに警告はされてるのでこの間に対応済ませているはず
多分……… そうならない様に技術者が対策してるから全く問題ない いつかは元号変わるわけで
下準備とか すぐに変えられるように 造っていない時点で
馬鹿だろうに
何回同じ過ちを繰り返すつもりなん 一旦内部表現になれば問題ないのだが、ユーザーインタフェース部分だけは
どうしても決まってから手がはいるので混乱がおきるのは仕方ない >>101
昭和100年問題もあってだな..
内部的にはまだ昭和が続いてる
システムもあるとかないとか マスタデータに追加するだけで動作確認くらいしかやることないわ あー、そんなのは、
米中やその日本政府内エージェントなど、
何枚か上手な連中に、
修正作業を観察されるソーシャルハックの部類のセキュリティホール比でマシ CNNは選挙時のロシアのハッキングがーとか言って無かったか
こんなこと言ってたら信憑性を疑われるし信頼性も無くすぞ ちなみ国際的にはUnicodeの標準化団体がカレンダーに関しても実装を提供してて
もちろん和暦に対応してる
今の所プログラム上は新元号はQQで予約されてるけどとりあえず5月1日の改元には対応してる
http://site.icu-project.org/home CNNは調査能力がないってアピールにしかなっとらんな ところで
今年度の税務署に出す書類は平成31年度分なのか令和元年度分なのか >>150
通信の世界だと、LSB/MSBの問題と、バイトオーダーの問題を何とかしてもらいたい
と言いつつ、問題があるとわかっていれば、ちゃんとテストで確認して対処できる。
>>1みたいな指摘は、要するに他人のやった作業を信用できないという話に尽きる。 >>157
みずぽ、対応できずATMが止まるwww >>137
キリスト教にそぐわないものを他に攻め入ってまで変えさせようとする価値観は今も健在だろうしな。 >>195
あれは古いシステムだとアカンっていうだけの話だから頑張るってより良い機会だっただけの話かと ないと思うけど 思わぬところで まさか ということをするのが人間
なんか起きても不思議ではないわ >>203
まずあり得ん
が、古いシステム生き残っててそれとのすり合わせならバグの温床になりかねない
この手の問題は組み合わせたときに発生する BBCには関係ないだろw
おまえらも紙面で元号を使ってるのかよw >>199
ユーザーインターフェースだけの問題なら、見れば一発でわかるのが人間というもの。 丁度30年の節目でご退位あそばされる明仁陛下は賢帝であらせられる。
もしこれが「崩御による改元」ならばコンピューター業界は混乱する 連日のように発生するウインドウズのバグに比べればどうって事ない事をみんなが知っている >>153
拡張部分で提供されてるんだ…
だとしたらそれ使ってるアプリはまずいな
教えてくれてありがとう でもWindows10なんかネットに繋いでないマシンでさえ一発変換されるね
Win7だと全く出てこないのに。 >>219
それがですね
最近いろいろと進歩したせいで手書きのH31とかS64とかを画像認識するような
やつもいまして、ここにR1とかを許すようにしなきゃならんので大変なんですよ。
キーボード入力や選択だけなら比較的簡単なんですけど。 昭和ならともかく昭和→平成を経験したのに問題発生ならSEがボンクラすぎるだろ >>222
官公庁とか生年月日をはじめ和暦が標準って書式は
けっこうあるんだよ。 CNNw 反日がいちいち心配するなw
誤作動するのはみずほ銀行だけです 西暦だけにしておかないから誤作動するんだろw
戦争犯罪者の象徴など使ってる馬鹿な企業が 2019年5月1日(皇紀2679年)は令和元年1月1日にはならないで、
月の方は5月のまゝ、あるいは2019年8月は令和4月にならないのはなんで?
どうせなら古風に1月:睦月(むつき)、2月:如月(きさらぎ)、3月:弥生(やよい)
4月:卯月(うづき)、5月:皐月(さつき)・・・とした方がより日本ぽくていいんだが。 >>3
ハズなんだが
普通にやらかすのが
コームインの凄いところ >>223
そうなんだけど、自民党の古屋元拉致担当相とか山谷えり子とか右派守旧系が
令和天皇が即位するまで新元号発表させるなという圧力掛けてたのは有名。 通名廃止しねえ?????????
。。。。。。。。 とりあえず e-taxがどのぐらいで対応するか観察しようと思います 内部では西暦計算ですから問題ない
表示上では元号付けてるだけで >>5
うちの会社いろんな案件
受注しまくって大もうけだったよ
大したことなにもしてないのにw 和暦採用してるOSとかあるの?馬鹿言うのも大概にしろ 和暦があるおかげでシステム屋が仕事もらえる
ありがたいこっちゃ >>230
データー入力とか画面表示と印字の時に年号でやってるだけでサーバーのデータベースは西暦で記録している。 >>217
在庫管理とか工作機械とかかな?
社員さんが大昔作ったシステムでその人もういない(生物的に)とか…
独自で勉強されて組まれているのでわからない
作った人褒めてあげたいけどお前らはちゃんと勉強して
金もらっててプロなんだろとか言われてもね…泣きたい >>246
知人のSEが役所関係は元号使用なので
金払いがいいって言ってた 環境変数つかってサクッと元号置き換えればいいんじゃないの
数秒で終わる作業をシステム屋は利益出すために色々理由つけてわざと数か月かかるようにしてるの? 最近の働き方改革で流行のRPAとかも
作りによっては影響くらうんですかね? >>249
ご愁傷様。
テレビのリフォーム番組でさえ、素人が独学で建てた建物のリフォーム改築案件は
建築士は誰も名乗り出なくて造園屋がやってたっけ。 >>242
昭和で2桁でやってたのもある
1960年代とかだと西暦2桁だと後40年しか使えないからとかおもってだろうかな?
99まで西暦よりもちょっと余裕がある昭和で良いやんと
どうせシステム全部代えてしまうんだろとかね >>254
役所系は文書や画面の体裁にこだわるばかりに、余計な処理が多い。 >>1
はいはい
もうCNNは終わり
アルジャジーラや新華社通信未満 2000年のときは1900年からの経過時間のカウンタがオーバーフローする問題だった
平成から令和になっても数字的には何にも変わらないから何も問題はない
こんなことで不安を煽るとか失笑してしまうわ、あはは >>250
そうそう金払い良い。
和暦使われているとこ全調査して出力して確認するので面倒出はあるが難易度低いおいしい仕事だった >>229
めっちゃ勉強になった
もうRも入ってるんだな >>50
2029年1月の仕事始めの日に役所の書類の日付が「令和11年1月」ではなく「令和1元年1月」と出力される程度の不具合はあるかも? やっぱりアマは、ごく単純なケースしか想定できないんだな 誤動作なんかないよ。
なんかあったらいったん「平成31年」で出力して処理を続けるだけ。 >>233
GPSロールオーバー問題
で間作すると良いよ
それ以外にもコンピューター言語で個別にオーバーフローしちゃうのもある
まあ対応済みがほとんどなので個人様はそういう事もあるんだな位で良いとは思うけど
そして2000年の閏年が400年ぶりの閏年があるかなり特異な閏年であって
2100年とかが4年に一度ではあるが閏年の無い特異な閏年という事も知らない人も居るかもね >>1 直せばいいだけ。
普段から出力値の確認もしないでそのまま使ってるアホは死んでよい。 まあエクセルも新元号対応パッチで
強制終了しまくりだったし 和号テーブル追加っと
1 M 明治
2 T 大正
3 S 昭和
4 H 平成
5 R 令和 >>235
職場はまだOA導入前(精々ワープロ機能しか使ってない)だし、
産業用コンピュータはほとんど西暦使ってたと思う 新たな救世主が現れて西暦がリセットされた時にも耐えられる仕様じゃないと >>271
GPSロールオーバーはあと8bitとは言わないまでも 4bit でも
拡張フィールドがあればたいがいの製品の寿命期間はカバーできたのにと思う。
いまの期間は絶妙に問題を起こす機器が使われ続ける可能性がある長さに
なってしまっている >>278
MSのアプデで一太郎の三点リーダやダッシュが縦書きでも何故か横書き表記されるバグは
嫌がらせとしか思えない >>279
エクセルの行を意味するRと被ってるからバグが出るかも >>139
マジで?
Switchは元号対応してないのか
やっぱり任天堂は糞だな >>272
まあそのはずなんだけどね
2000年問題の時にいろいろと警告してるのでたぶん大丈夫
その時してなかったけどお金が出来たらするとか
時間が出来てからするとか
いろいろと言ってたな
してるのかな… >>288
エクセルで R1 を見たときに Raw 1 か年号か解釈があいまいになる可能性があるんだっけ?
だとすると、少々話がややこしくなりそう。 Showa > Heisei
Showa > Reiwa > Heisei
比較分岐とかしてると有り得る哉 日本のシステム業界における
三大改修案件
「消費税導入対応」
「平成追加対応」
「2000年問題対応」 >>294
工場とか産業用とか余裕でこれからも使い続けるよね
一番使い捨てて更新されやすいのが人間でした >>1
これは、最初から分かってた。
だから、もっと早く発表すればよかったのに。
何をいまさら。 >>299
発表して一ヶ月程度で運用が始まっちまえばgdgd文句言う馬鹿が少なくなるでしょ
どれだけ早く発表したって文句言う馬鹿は言いたいだけだから言うし 和暦変換は平成の方が複雑だった
昭和は西暦の下二桁から25を引いて和暦変換するか、足して西暦変換するだけ
令和は18を引いたり足したり
しかし平成は西暦下二桁が88以上は88引いたり足したり
88未満は12を引いたり足したり
平成は複雑すぎた まぁ細かい問題は色々起こるだろうね
元の管理自体はシリアル値だろうけど >>9
basicは今でもつかわれているけど?
VBとしてな。 平成への改元の時にはさして問題にならなかったが、現在では問題を
起こしそうなもののリストってどんなもの?
ここまで見たものでは次のようなのが挙がってる
・帳票などをOCRや画像解析で入力するようなもの
・excel他Rで始まるものが特殊な意味を持つなど厳密な文法ではなく
文脈で属性を判断する可能性があるもの
・自動操作をやるRPAなどのロボット
・Siriやスマートスピーカーなどの音声入力 Unicodeでの「令和」文字はU+32FF (㋿)だそうな >>228
平成が選ばれたら64足す簡単なお仕事です。 >>307
PCと言ってもNECの98シリーズを使ってる工場とか有るよ
DOS3.3Dで元気に動いていたよ >>309
数が全然違うじゃん
皆 まめ電話とか持ってるし >>307
そのころ作ったソフトが昭和2桁管理とかで動いてる分がある 元号で動いてるのとかは無いけど
印刷ミスとか沢山出てくると思うよ >>312
SEというより
発注側からかねねんだわと言われて根本的な解決できないけど
そういう対応で簡単にごまかせますけど
後ほどお金が出来たら変更してくださいね
というのはあるんじゃないの?
それかどうせ全面的にシステム変更するんだからとその時はしないで良いよ
と言われたら変更してはいけない >>318
それって、今でも昭和換算で計算してるの?
だったら改元より昭和100年問題がもうすぐ起きるじゃん >>289
次のアップデートで対応されるから心配ない。 バ ク サ イ のニュースでもえらい盛り上がり様である これな、英字に略して書く時RのL分からない年代多いぞ
平成はHですぐ分かるが、日本人の苦手なレフトとライトだよナ >>320
何かの管理するにも年が要るのならまあ普通に…
年管理をほんとに必要で使ってるかどうかはモノによるんだろうけど
有るものは多い ネットで確定申告する時に子供の生年月日を平成で入れる画面があって、一瞬戸惑った
役所系は面倒だな
外国人も利用するんだから西暦で統一すればいいのに >>326
発音はLのが近いんだっけ? でもローマ字表記でLは無いし 何故元号で不具合が生じると思うんだろ
基本は西暦で日付計算をして、表示するときに元号に変換するだけなんだが アメリカ製のプログラムなら日本の事情を理解する気が無いのでレベルの低いミスもありえると思うよ
やらかすのはMSだと思うが コンピュータは西暦で計算してるかもしれないが
元号表記に自分が対応できないと思う
自分の免許証の更新は令和何年になるんだ?
保険の一時金が保険証書をみると平成59年に受け取れるんだが
その間にもう一度改元なんてされたら分からんわ! >>333
1980年代に構築されたシステムだと、年を2桁で表すのなら、西暦より昭和だろう。
あと40年は使えるし、昭和100年にはこのシステムは無くなってる
と当時は思うよ。 銀行は未だに和暦大好きだからなw
新元号モロに出力する部分の改定はこれからだぞ てか2000年問題で何が問題だったか理解してないだろw RFPさんがスクショから元号読み取ってるシステムが一つくらいありそう 朝鮮人が火病中 ばーど =僕ら= ガーデイス
↓
核酸で
●中国外務省の耿爽(こうそう)報道官は1日の記者会見で、
新元号について「日本の内政であり論評しない」と述べるにとどめた。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
論破
元号批判に中国を利用するなってよ、卑劣な 朝鮮人
重要★
※ 中国の命令された元号を使われていた属国国 朝鮮
※ 古代 日本の独立した 元号を使えた 国 日本
248代目の 元号 万歳 ばんざーーーーーーーーーーーーーーーーい
在日朝鮮ジン工作機関 朝日
の嫌がらせまとめます if LEFT(nendo)==='M' then
...
else
raise(err)
みたいなことやってるプログラムが無いとは限らない。世の中広いからなw >>43
>システム開発の人が元号を変えるのは意外に手間隙がかかり難しいというようなことを言っていたよ。
難しくねーよ とにかく動作確認に手間隙が掛かるだけ
時間とマンパワーだけの話だ 今時のプログラムは内部では全部西暦だし・・CNNって馬鹿だなぁ
古いやつの昭和100年問題は2025年なのでもうちょっと先 >>323
レガシーシステムが減ったとはいえ
それがかなり問題になってるの知らないの? 仮の元号(例:◆◆)で十分試験してるでしょ
まあ中には◆◆をハードコーディングしてる奴がいるかもしれないがw >>323
ズバリ「昭和100年問題」という用語があるw 鉄道関係やけど、ほぼほぼ
改元対応=西暦変更
なんだよなあ…
だから既に殆ど改元対応済み。今日の発表もあまり関係ない。
本音でいうと、業務からして仕方ないとは言え
令和は昭和や平成より馴染みが薄くなるってことなんで悲しいなあ。 元号はアウトプットの部分だけでしょ
ロジックに元号使ってたらそれはそれで凄い >>360
元号→西暦と変換したい時もあるからそうでもない >>54
ゴム印ポンポンが一番簡単だよ
急がば回れ! >>364
ゴム印で修正された領収書をスキャナで取り込んで認識するのって
ちょっとうっとうしい処理がいりそう こんだけ準備期間があって誤作動させるようなエンジニアは死んでいい あらかじめ関数作るだけじゃなんか不都合あるのか
プログラム全体の一ヶ所だけ新元号に書き換えるだけで済むはず かなり前から告知していて元号発表から切り替わりまで一ヶ月の猶予があるのに
これで誤動作するとかどんなゴミシステムだよ >>366
準備期間があっても金と時間を誰がどう出すかが一番の問題だからな。
技術者側の責任じゃないよ。 平成元年に比べたらIT資産は桁違いに増えてるからなあ >>367
修正はそんなもので10分で終わるどころか
不要なシステムがほとんどだが
問題がないかどうかの調査とテストに膨大な時間がかかる。 >>352
>>354
2000年問題が話題になってから20年も経ってるんだからさっさと改修すればいいのに >>54
平成になった時に訂正ハンコで上司の名刺を訂正しまくってたわ ばかじゃねーの
何のための公表だよ
そのために色々期間決めて準備してただろうが
フェイクニュースといわれる理由を考えろ まあ、最悪平成31年、32年とかで動くからたいした問題にはならんだろ。 もうとっくの昔に対応してます。
ついにこの機能が動く時が来るのかと 未だに紙媒体が大多数を占めている日本へのブラックジョーク >>46
その問題も、すでに問題ではなくなりつつあるけどな
64ビットCPUが増えてるだろ、long が64ビットならオーバーフローは発生しない
2038年に32ビット以下のCPUがどれだけ残ってる事か・・・ MSはLLP64だがな
まあtime_tはlongじゃなくて明示的に64bitに変えられたけど >>383
西暦→元号変換の関数を、コピペするだけなんじゃねぇのか?
ライブラリ化してるならリビルドするだけだろ >>384
そうだったな、sparc も同じだった気がする
でも tine_t は long long に定義変更されただろ、unsigned かどうかは知らんけど >>385
COBOLだもん・・・
おまけに歴変換、元号名腹抱え多数ww
汎用機からオープン化したときに資産コンバージョンでCOBOLそのまま使ってるから
正直手に負えん アカヒ新聞NY支局NYT
アカヒテレビの川豚も火病ってたなw 令和の令って手書きの時の書体が複数ある上に類似の字が結構あるから
文字認識処理で鬼門になりそうな気がする。
大丈夫かいな。
令01-05-01 って認識しづらそう 東海地震くるくる詐欺で防災グッズ死ぬほど買わされた東海民のように騙されているだけ まぁ誤動作と言うか
国税の申告西暦にしてほしいわ
法人税別表、完全に形骸化されているのに添付しろというアホ
そもそも国税が手形の期日とか知る意味あるん?
月1万の不動産の借りている内容まで出せとかアホか
この国の税制はホント無駄が多すぎる >>396
国税で思い出したけど、
今年度分の申告書類は平成31年度分になるのか令和元年度分になるのか。
平成に変わった時には1月だったこともあって昭和63年度分と平成元年度分に
素直に分けられたが、今回は5月切替だからどうなるのだろう。 そんなことで使えなくなる会社はクソだから良い指標になるよ。
今後なんかの更新で失敗する可能性があるってこと >>373
2000年問題の頃、
「うちは昭和通年方式だから無問題ガハハ、2025年?そんな先までこのシステム使うわけないでしょ」
こういう社長たちが、実際多かったんだ >>305
本当は複雑ってほどではない
0年0月0日を仮に認めてしまえば、あとは単純な加減計算で済むよ
つまり25年で昭和換算するのと同様の話で、1988年を平成0年扱いにすればいいだけだよ
時分秒でゼロを使うのは、体感的に秒なら分を、分なら時間をまたぐ瞬間を感知できるのと、またいだ事を位取りで表現(加減で計算)しても矛盾をきたさないため
年月日でゼロを用いないのは、おそらく(秒ではなく)時が日をまたぐことを体感しづらくずっと放置されてきたからに過ぎない
つまりは社会の怠慢で我々は今も欠陥暦法を使っているからに過ぎない
計算時に内部でこれをゼロから始まる体系に置き換えればいいだけ
0年0月0日を認めてしまえば、全部が単純な加減の計算で済むよ >>307
>>281
西暦がリセットされても内部仕様はそのままだよ
なぜなら西暦で動いてるのは外部とのインターフェイスだけだから
本当のコンピュータの内部暦は、エピックからの経過秒数 >>1
元号ってコンピューター時代に逆行してるだろ? 入出力だけ和暦であとは西暦のシリアル値だろ
3桁の表示域でもない限りは止まるとかあるのか 西暦変えるとしたら人類が宇宙へ移民を開始したあたり? >>404
西暦ですらなくて、エポック秒とかPOSIX秒だろ。 >>366
間に合わねえから仮元号入れて
テストしてるのとか知らねえんだろうな 民間「2000年問題の二の舞にならないように早めに発表してね」
政府「やだ、盛り上がらないじゃん」
これ最高に阿呆でしょ 知らない人いると思うから一応書くけど2000年問題は発生はしてる。
フィリピンかどこかアジアで水道メーターとタクシーメーターがおかしくなった。
ちなみに平成の元号が発表されたときの反応はスタジオアルタ前の若者たちが
「えぇ〜、平成(なんだかっこよくないじゃん)」だったけどマイク向けられると
「平和に成るでいいんじゃないですかね」と当たり障りなく答えてた。
平和に成るがあまりにもそのまま過ぎて不満だったんだよ。 せいぜい文字が化けるぐらいで、それ以上の問題が起きるなら元のプログラムの作りがアカンわ。
うるう秒よりはよっぽど簡単なんだがなあ… >>412
レガシーシステムだと、データが
|H|19|04|30|
↓
|R|01|05|01|
みたいな変化することもあるんだよ
日数を計算するだけでも、結構な手間、バグの元 >>25
和暦2桁で保持してるシステムがあったりするんどけど? うちのxpは本当にヤバイな。
jrの2000には、敵わんかw
どうなるjr?
止まるの?その為の10連休かw >>410
当たり障りなく
当たって障ってたら放送しないw >>405
ガンダムは、宇宙戦艦ヤマトの様に2199年とやると夢がなくなるからだろ。
実際は変わらん単なる時の流れ 2000年問題は処理に問題が起きるけど、改元は別に平成表記が続くだけだから問題ない >>419
本当は2199年なんて未来がないことを知っているので宇宙世紀な、
ここだけの秘密 平成元年頃って言うと
windows3.0すら発売
されてなくてDOSベースだった?
で、なんのトラブルもなく
移行できてるの?
いちいち掘り起こすの
面倒くさいから 出来ないなら令和がコンピュータをぶっ壊したら面白いのに excel2003愛用の俺新元号目前に震えが止まらない 誤作動じゃねーよ
目的の操作ができるように、人間がきちんと設定できてないだけだろ
コンピューターは悪くない、人間が言った通りにちゃんと動いてる
そもそも、元号をコンピューターにまで入力しようとしてるのは日本人だけ
元号を持ってる国は他にもあるが、免許証まで元号で記載してる馬鹿は日本だけだよ >>415
例えば?
西暦を和暦に換算してるだけだろ? >>17
大丈夫。北朝鮮がそろそろ核撃つから
でも北朝鮮の核だけで世界終わらす方法は? >>431
北の核だけで世界終わらす方法ある。
世界最大規模の火山数十山かに打ち込むと終わるな。理想は数十発準備がいる。 世界三大くるくる詐欺
ベテルギウス
太陽フレア
ポールシフト
世界経済破綻
南海トラフ
芋づる逮捕 よし、色々勉強してきたぞ。
・元号の開始は645年の大化だが、元号使用を中断してる時期があった。
・紀元前に102年間天皇を務めた方がいる。天皇が空位の時期もあった。
・南北朝時代は2つの元号が同時にあった時期がある。
・中国の元号が途切れたのは1945年の満州国時代の溥儀の時。これって日本が悪いの? システム的には西暦で管理してるって書いてる奴もいるけどそれも間違いで
日付時刻型のデータになってて(ある基準時からの通し番号)
西暦でも変換かましてる
和暦を数値としてデータ格納してたりするシステムは空前絶後のバカシステム
普通は無い >>436
中国の元号は清の滅亡で途切れたとするほうが一般的じゃないかな。 まぁ可能性はある 元号が変わる可能性まで考慮してプログラム組むヤツはいない 意味不明すぎる
元号というカテゴリの漢字コードが変わるだけや
あほらし >>442
新卒のころに入社した会社(かれこれ20年くらい前)の業務ソフトでも
元号マスタ持ってて西暦何年何月から和暦は××ってレコード追加すれば
画面表示・印刷に全反映される仕組みになってたぞ >>358
2,3枚失敗するかもしれんがあとは楽なもんよ
白いコピー用紙に印刷して重ねれば本紙じゃなくても位置合わせはできる
あとはプリンタ任せだからせいぜい一年程度しか使わんハンコもいらんし
ハンコついてる時間に他のこともできるわ >>436
天皇一代に一元号になったの割と最近じゃなかったか >>444
PC自体がクラッシュする事は稀だろうけど
実際問題使い物にならない事案は相当数あるだろう
元号自体を追加で設定できるようになってるとは
思えない パッチで修正可能ならいいがそれが
元の価格に含まれてるかどうかは別問題 なんでパヨクはここまで改元に拒絶反応を示すのか正直理解できん
韓国がパクれないからか? CNNが指摘ねぇw
まぁ日米同盟破綻の折には日本のインフラをぶっ壊すプログラムを仕込んだ米国だから
よーく分かってんだろうw >>450
韓国がパクれないからか?とは何事だ!馬鹿にしないでよ。
韓国の元号は日本より古く高句麗時代の391年の「永楽」からあるぞ。
むしろ中国からそのままパクって朝鮮独自の元号が少ないんだ。
そしてどっさり省略して1894年からここ100年余りを見ても
開国、建陽、光武、隆熙、明治、大正、昭和、元号なし、大韓民国、檀君紀元、西暦紀元
と文化彩り豊かに今も脈々と続いてるんだ。 >>449
世の中にバカなつくりをしてるバカシステムがどこかに存在してるというのはあるかもしれないけど
俺の体験談だと余裕で対応してた
なんちゃって改元しまくってテストしてたよ。当然のように標準機能の内だ。パッチどころか設定UIで設定するだけ
だいたい改元って突然天皇が亡くなって突然起こるのが有り得るものなのに準備してないとか頭が狂ってる 普通UNIX時間で処理して表示上のみ和暦に変換するから誤動作なんてするわけがない
ちょっと表示上のプログラム変更するだけの作業を大変だと大騒ぎして
変更作業の料金釣り上げるやり口
そして和暦をやめさせたい勢力が利用してる 内部処理に和暦なんか使わん。
表示用に処理して出力するだけ。
誤作動のしようもない。精々エラー表示吐く程度。 内部処理には使わんだろうけど和暦→西暦変換がバグって西暦0年とかで処理されちゃう可能性はある ほんとうの地獄は10日のwindowsupdate後 ERPでもデータベース格納は西暦変換じゃないかな。
入力画面や帳票でコンフィグ参照のうえ、見せ方を切り替えてるだけで。 精々文字化けぐらいだろ、起きるの。
未だ2桁のみです処理しているような物は知らんけど。 昭和100年問題なんてのもあるから小手先パッチで済ませてるシステムあるかもな
内部的には平成も昭和2桁で計算してる奴 例えば自動車税とか課税日から
一ヶ月しか無いのに
改元して尚且つ発送とか
できるのかね?
なんか必死に問題ないって
笑える 新年号への修正と修正バグの修正に10回位はアップデートさせそうだな; >>454
平成33年という入力も有効にしてほしいとか、
既に平成33年と入力してるのはそのままにしておいてほしいとか
そういう要望に工数かかりがち 苦労して元号を決めて、苦労をもたらす
見て下さい。これが日本ですよw
ドMなんてレベルじゃないわ それ"だけ"だと思って見積りしたバカな営業がいてな・・・
長期で運用されてる基幹システムの闇を知らない素人は、事前に専門家に相談しとけ >>464
入力の方は問題なさそうだけど、平成33年表記は難しいな
どんな理由で必要なのかも謎だけどw >>464
入力受け入れの方は簡単だよ
”平成”の部分で条件分岐→基準年の1989を取ってくる1989+33-1=2021年で一意に計算できる
令和に切り替わる前だろうが後だろうが計算式は一緒
出力の方を場合によって平成33年と令和3年分けてくれと言われるとどこにそんな条件分岐入れるねんと混乱する >>236
危惧すべきはコンピュータのやらかしじゃなくて事務作業時のヒューマンエラーだよな
公務員に限らずだけど コンピューターのプログラムって元号で動いてんの?
表示される元号を変えるだけじゃないの? >>470
厳密に言えば西暦でも元号でもない
1970年の基準時からの経過秒数で動いてる
データベースなら、西暦で保存してる例も有るけど、元号で保存してる例は聞いた事が無い 前の元号切替は1月8日だったから、あまり問題にならないけど、今回は単純に年の引き算だけでなく変換には月日も勘案しなければならない
具体的には2019年は平成31年と表示させるか令和1年と表示させるかは4月以前だったら平成、5月以降だったら令和としなければならない
以前はコンピューターが使用されてなかったから1989年は平成1年で取りあえずは問題なかった 元号を利用するソフトで元号が変わるとコンピューターが誤動作することなんてあるの?
せいぜいユーザーが元号を書き換えられるようになってなくて
令和が表示できないとかその程度じゃないの >>471
システムのdate epochの話なら1970年はあくまでunix系の話であってWindowsは1601年だしOSXは2001年 >>478
Windowsのエポックタイムが1601年?
time_t が32ビットだった時代はどうなってたんだよw
OSXとは Mac OS の事か?
Mac のOSもUNIX系だよ、Mach をベースにしてたんじゃね? >>480
FILETIME なんて使った事ないな
しかし、time() と異なる体系をタイムスタンプに使う理由が判らんな
現在時刻と比較するのに不便だろ
何の理由が有って、そんな謎仕様になってるんだ? 2038年問題は着々と解決されてるのか
どこかで古い核ミサイルが誤動作しないのかw >>468
-1が不細工
年月日はOption Base 0で計算すべし 今日台場でAI OCRとかいうものを見て来たが
あれは改元とかあると学習し直しになるんかな 銀行の振り込みデータは和暦だったな
使ってるとこあるのか知らんが >>43
無知な人には金を引き出すために大変沿うに言う
実際はマスタに1データ追加するだけよ >>483
改元は1989/1/8や2019/5/1など年月日まで決まってるもんだから
計算式の-1を避けるために基準を1988など意味の無い年で登録する方が不細工だろう >>486
修正自体が難しかろうと簡単だろうと、テストの負荷は変わらんからな oracleでもdate関数のパラメータ次第で和暦返してくるのに >>488
まともなシステムだとどのタイミングで改元が何回来ても対応できるようにテストしてある
商品や顧客のデータ増やすたびにテスト全部やり直す馬鹿はいない
改元も同様に作り込んである OSのパッチ当てたりしてシステムが正常に動くか確認しなきゃいけないが
オンプレミスの会社でテスト環境持ってない顧客いるからなあ
再起動が必要なケースもあるから繁忙期外して停止するところは結構出るのかな 恐れも何も
既に1月のWindowsupdateで元号バグでマクロ動かなくなってただろ 日本で話題になったことをCNNが報じただけの話じゃん
何が「指摘」だよw >>487
ゼロとマイナスを含む整数は、引き算で矛盾を生じないように定義されてる
日付をずらすんではなくて、ゼロから始めるのが正しい
ゼロ時ゼロ分ゼロ秒と同様、年月日もゼロから始めるべきなんだよ >>494
令和0年からにしろって言ってるの?
現実はそうなってないのに何を意味の無い事を言ってるの >>490
残念ながら、過去に仮元号でテストをしたからといって、本当に現在の環境で改元して確実に動作するという保証はできない。
テスト後に作られたシステムが規定された方法で和暦変換していない可能性もある。
だから、過去にどんなにテストをしたからといって、テストしなくていいシステムなんて存在しないよ この指摘は重く受け止めたほうがいいでしょうね?
何が起きるわからないんだし 可能性は無限大
バタフライ効果も含めると地球規模ですね >>494
「始めるべき」って、現実世界を無視してシステムを作れといってるの?
それともシステムが対応しやすいように、社会の仕組みを変更しろと言ってるの? 元号ベースで計算してるシステムとかないでしょ。
バグがあっても表面的なもんだろ。 今更改元で困るシステムなんかあるの
あったらぜひメディアで紹介してほしい うちの会社は、今年いっぱいは平成31年のままいくってさ >>248
データベースで和暦求めてくる官公庁はあるよ
新和暦と略称を指定して1日には対応するようにと文書が来た 今回の改元は、今までに無い不具合が出る。
しかも半島がらみという意味不明のシチュエーションで。
令の字にUNICODEのコードが
CJK互換で別のコードも割り当てられてるのが原因。 >>492
Windows は元号対応してるんか?
そんな義理は無いと思うんだがなぁ・・・
Exel は対応してるのかな? 「令和」の典拠だが、この言葉がそのまま出てくるのは
『文選』でもなければ、『万葉集』でもない。
『黄帝内経』という中国の鍼灸医学の古典に出てくる。
で、この『黄帝内経』という本の内容はまず大きく、
「素問」と「霊枢」
に分けられてる。
その「霊枢」の中の九番目の章「終始」に
この「令和」という単語が出てくる。
冒頭から3行目の最後に。以下引用。
凡刺之道.畢于終始.明知終始.五藏爲紀.陰陽定矣.
陰者主藏.陽者主府.陽受氣于四末.陰受氣于五藏.
故寫者迎之.補者隨之.知迎知隨.氣可「令和」.
で、ポイントはまず「霊枢」という言葉。
露骨に「霊柩車」を連想させる。
さらに「終始」という章の名前。
まるで「終わりの始まり」。
だから「令和」の時代は日本の「終わりの始まり」であって、
その結果日本は「霊柩車」に入ることになる、
と解釈も出きるんだよね。
いい年号だなw
どおりでネットでさえこの『黄色内経』には言及しないはずだ。
針の本だし「日本はもう死んでいる」ってことかもなw キャハッw ざまみろ死ね糞ジャップ
^ 元号表現だとソートするとさ、
元号混ざってるとちゃんとソートしてくれないじゃん? >>299
ダミー年号で作り込んでおくでしょ、普通。
それができない奴はゴールデンボンバー以下w >>511
言っている意味は分かるが、通常元号はコード化してリテラルとして扱わないので
そういうことにはならない。
エクセルだとシリアル値としてソートされるので、これも問題ない。
まずいのは、和暦表記をそのままテキストとして扱った場合かな。 >>513
通常だと、日付計算をする関数が用意される。
自分でどうにかしているシステムであっても、共通ルーチンか外部関数化していて
元号テーブルに
昭和 1925xxxx,19880105
平成,19880106,20190430
令和,20190501,99991231 ←を追加するだけ。
リテラル打ちしてるプログラムがあったとしたら、それはプロでなくてバカの仕事。 帳票の日付フィールドのフォントがプロポーショナルフォントになってるのはありそう
令の字はwidthが狭そうだから問題ないかな >>515
普通はそうなんだけど
そのテーブルを参照するSQLに開始日<SYSDATE<終了日の条件が抜けてるケースは見たことがある 開始日≦SYSDATE≦終了日
でした>517
どうでもいいけどw あと締め日や営業日のところをSYSDATEにしてたり
まぁ色々出るだろうね
笑って許して。。。。くれないかな テスト
U+4EE4 令
U+F9A8 令
2chMate 0.8.10.45/Sony/SO-02H/7.0/LR 2000年問題より2001年問題の方がデカかった印象。
年を2桁で入力していると年月日で入力したハズが、月日年に勝手に変換されて帳票処理がえらい事になったよ。
次いで2004年問題。
古いtime_t型だと二つの日付の中間を求める時に、日付を足した時点で桁あふれしちゃうって奴。 >>150
統一は難しそうだからせめて西暦は4桁で表示してほしい
年が確実に慣ればあとは推測しやすい 預金がおろせなくなったり、残高が減ったりすると怖いな。
令和には、零で割る意味もありそう。
division by zero. 令和詐欺とか絶対来るよな
元号が変わると現金が引き出せなくなるとか何とか言って れいわるれいわれいわまちがい。
0÷0=0は間違い。 俺、仕事で改元対応やっているよ。
対応そのものより、本部への報告対応で疲れる。
つまらんことで何度も質問してくるんじゃねえハゲ。 >>515
ホントだ、設定値エラーあるな。始末書ものだ。 いつも同じようなことで騒いでるけど実は問題なのは官庁のコンピューターだけなんじゃねw 保持してる時間は西暦ですらない。
元号で扱うアプリが入出力の時に変換でしくじるくらいだろ。 即位の日に全国の全システムが一斉に令和に切り替わるのは胸熱 古いバージョンのOS、
たとえばWindows XP, 8,7,2000、Me、98,NT4, NT, 95,MS-DOS
などでは、パッチが出ないから平成35年とかの表示が出続けるのかもしれないな。
古いアプリでそれらのOSでしか動かないものを動かし続けたいことはあるからね。
またアプリもそれらの新しい年号には対応していないだろうし。
LinuxとかMacOS、FreeBSD, NetBSD、。。。なども、
古いバージョンのOSとアプリを使い続けたいことはときどきある。 一般家庭ではPCで元号って年賀状ソフトだけだよな〜 あるで
昭和から平成になるとき
30年で判定して下なら平成、上なら昭和とかやってたプログラムあったし
あれじゃ今は使えないからどうなってたんでしょうねw
またそんなことやるんかねw >>534
OS自体が元号を扱ってる部分なんて有るのか?
上に乗っかるアプリが元号対応してるだけだろ >>1
アホか
プログラム上は、キリスト歴使ってるよ
これ常識
計算は、キリスト歴
表示は、和暦
これ、業界のあるある話
西暦だってキリスト誕生に合わせた改元に過ぎないのにな
それも数年の誤差があったというオチがついている恥ずかしい基準でしかない >>1
これはCNNによる工作
元号が良くないものであることを流布する印象操作
だって、CNNはブサヨで民主党シンパ
日本を日本でなくしようとする反日工作報道なのである
米国では右の共和党でも左の民主党でも国益を優先するが、日本においては左は売国
このことを戦後の民主教育に名を借りた洗脳教育に影響された愚民は気付かない >>535
家計簿ソフトやExcelもあるんじやない?
ウチのExcel 2007はレジストリをいじっても新元号どとろか平成も変更出来なかった。
Excel2007本体かdlllにハードコーディングされているのか? ゼロ日と閾値であり有効になる施行日は最初に一括して宣言、
コードのあちこちに足す一とか引く一とかをバラまくよりかはよっぽど読みやすいね
>>500
流れからしてプログラミングの話だろ >>542
弥生っていう会計ソフトの会社から新元号対応の更新するからダウンロードしろって案内が来た
何か関係あんじゃね? マイクロソフトがやらかして、WindowsOSのPCが全停止するのかー
TRON復活確定でづね 電卓の税率みたいに、元号のボタンとかあったら大変だろうなw ■ このスレッドは過去ログ倉庫に格納されています