大企業「よーし会計システムを新しくしたぞ!」(2021)→3年後の2月29日、うるう年すら想定してなかったためシステム障害 日本もうダメだろ… [597533159]
■ このスレッドは過去ログ倉庫に格納されています
神奈川、新潟、岡山、愛媛の4県で先月29日、運転免許証を発行する機械にシステム障害が起き、一時、免許証を発行できない事態となりました。
警察庁によりますと、免許証を作る機械に「うるう年」の設定がされていなかったことが原因だということです。
「うるう年」が原因のトラブルは、他でも発生していました。
大手ドラッグストアのスギ薬局でも管理システムに障害が起き、全国の店舗で一時、処方薬の会計ができなくなりました。
スギ薬局によりますと、3年前に現在の会計システムを導入。
初めて2月29日を迎え、過去の記録がなく障害を起こしてしまったということです。
薬の処方に問題はなく、会計ができなかった客には後日、代金を支払ってもらうとしています。 文系のくせにうるう年すら知らねえのかよ上流工程(笑)コンサル(笑)くんは 仕様書にないからな
あえて対応する必要ない
問題あればまたお金もらえるし DATEでもってたけど前年同日比とか参照してたんじゃね記事によると
でdivエラー うるう年とかJavaレベルの言語でも関数あるんだが… プログラムでカレンダー処理勉強してたら最初に気にするところだと思うけどw ていうか、カレンダーくらいは既存のライブラリ関数とか使わねーのか?
カレンダー関数なのの返り値を処理するのでバグってたのか? 暦を変えよう
一年を364日にすれば曜日と日付が不変になるし四半期ごとに31日にできる
余った日にちは数年に一度一週間単位で調整していく ライブラリとかにうるう年判定とかあるやろ
一体どういう作りになってんの?
謎もいいとこだわ うるう年ぐらいで問題起こすなよ
y2k問題のときはほとんど何も起こらなかったのにな
こういうところでも国力が落ちてるのを痛感する うるう年すら考慮せずシステム設計してるってレベル低すぎん? いくらなんでも免許の発行でこれはだめだろう
どんな開発してんの こういうのテストで出てこないんだよなぁ
実際にうるう年にならんとわからんから なんでケンモメンってプログラミング詳しい人いっぱいいるの?(´・ω・`) みんなすごいね 日本人は英語読めないから既存のライブラリや技術を使わず、すぐ車輪の再発明始めてしかも出来た車輪はバグだらけのゴミなんよ 多重請負のせいだろうな
末端のクソみたいなエンジニアが書いたコードがそのまま使われたんだろ すぐに技術者入れ替わる使い捨て&ブラックだから
基本のキのうるう年の設定もなんもなしなんだろ
納品したらおしまい
どうせ俺は4年後だかうるう年の時にはいないしどーでもいいやw
っていう これが韓国の話だったら
面白いゆっくり解説動画が3つはできる 俺が作ったエクセルのマクロですらうるう年は考慮したのに… >>18
150年後ぐらいには8月に冬が来るわけだろ
別に良いんじゃね? 前年の同一日とかを参照するようなロジックがあったんじゃねーの
流石にライブラリ使ってない現場はねーよ 開発者が閏年知らなかったって事だよな
ありえないだろ
ジャップの知能低下は限界突破してるな まあうるう年って東アジア独特の文化だから間違えるのも仕方ないよね 前年同日を比較するシステムでうるう年想定してないって
どんなゴミシステム屋だよw >>2
薬局は【処方】できない
できるのは【調剤】 うるう年は当然として、うるう年が除外される2100年/2200年/2300年もシステムに組み込んだなぁ if (month == 2 && day > 28)
printf(“日付エラー”)
exit(1) date型じゃなくて文字列をそのまま入れてたってマジ??? >>49
まあ4年に1回しか来ないなら直さない手もあるな そういうときにハンド対応するために人がいるんじゃん >>50
俺も100年後を想定して対策いれたことあるわ
絶対そこまで使われねえと思ったけどそれから20年経ってもまだ毎年新バージョンがリリースされててビビる 埋め込みでもしてたのかね
ライブラリなり参照してたらいい加減起きないだろうに 日付のライブラリにうるう年てセットされてるんちゃうの??
わざわざカレンダーから作っちゃうもんなの?? ぶっちゃけ他の大企業でもうるう年トラブル多かったよ
日本最高レベルのブランド企業でもね コンピュータ「人間ハバカダナ、二月ハ28日マデシカアリマセンヨw」
相当なポンコツやぞ
AIが人類を支配するとか永遠に無いだろ うるう年まで待てないから日付関連の機能テストは最低限とし、残りは机上設計確認とする! ライブラリ使ってたら起きようが無いと思うんだけど
わからんな テストどうしてたんだろうね?年を扱うならやってるんじゃないの? 優秀なSEなら100年に一回どころか400年に一回も想定してプログラム作ってるぞ >>29
生成AIが出てきたせいでもうほぼサラリーマンの基礎知識になりつつある ライブラリがないにしても糞昔からうるう年判定のコードなんて腐るほど転がってるのにな
いやマジで腐ってきてるわ日本のIT これわざとだよ
なんでかってのは発注側が言わないし金も出さないから 先々ありそうなチョンボとか人のやりそうなミスを予想して声掛けたり潰してくタイプの人減ったよな >>80
そんなんしても金にならないどころか不要な責任ばかり増えるだけだし 発注側の要件に書いてなければわかっててもしないんじゃない? わからないんだが…
https://web.archive.org/web/20190406043653/http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8 前年の同一日の情報を取得出来なかったっぽいけど
ライブラリ使えば2/29の前年日付でも存在する日付で算出出来るやろ
というか2/29の前年日データをどうするかの仕様決まってなかったのか、決まってないから上流のテストで弾けなかったんだろうけど
そもそも前年月ならともかく前年日データなんて何に使うんだよ、うるう年の面倒な決め事までして必要なデータか? まあ、仕様と実装どちらも多重責務で流せば起こりそうなミスではある
上流から下流まで脳死で働いてるからこうなる。上流は搾取し続けるし下流は搾取され続ける
体制が破綻してるから事故るわけだ 日付処理じゃなくて、前年の同日を参照できなかったのね
それは起こりえるし、テストで潰せないバグだわ うるう年が設定されてなかったって、どういう意味だろ
ロジックでうるう年か判定してるんじゃなくてうるう年テーブルみたいの見てレコード有無で判定しててレコード入れてなかったとか? 全国じゃなくて4県ってのがな
都道府県でバラバラのシステムなのか >>46
こういう指摘チョーうざい!
な~んちゃって 8年間うるう年ない場合もあんだろ
昨日まで知らんかったわ 無能なので下手に考えず他人のソースからうるう年計算ロジックコピペしといてよかった 実際に作ってるのは最低賃金スレスレの奴隷なんだから言われたこと以外やらないよ
そういうとこまで考慮してやってほしかったら多重やめなよ
間に挟まってエクセル弄ってるだけのウンコを排除しろ まあこれIT技術ってより一般教養だよな
IT業界には一般教養全く無くてプログラミングしか知らなくて自分のこと天才だと思ってるやつが多いからな 四年に一回くらいならええやろ気にすんな
ビビリか! >>79
アホというか
一回作っておけばそれをコピーしてつくるだろ
ずぶの素人が全く一から作ったのかい 4県だけだからNTPの設定があるけどしていなかったとかもあるんじゃね >>95
これよな
残業代出ないのに自分から残業発生する指摘するメリットがない
有能扱いされても給料増えないのが派遣だし こういうのこそコピペでいいんだよ
できない奴は自分で1からやろうとする >>85
そうだけどリニエンシー許容指定してないとエラー返すライブラリ多いよ観点から漏れてたんじゃねーの
突貫で作ったら普通にありえる こんなプログラミングの基本的な問題のうるう年に誰一人気づかなかったのか 仕様書にないからセーフいう奴おるけど
1年365日固定の独自仕様の暦を採用するとは仕様書に書いてなかったんだろ
だったら世界標準の暦に準じなければならないのは当たり前だよね パッチ作ったよ。使ってくれ。
if year = 2024 or year = 2028 or year = 2032 then feblastday = feblastday + 1; 業務系って仕様書にないことはやらないからな
エンジニアというより考えることもコミュニケーションすることもできないただの作業者、コーダー 要求仕様書が絶対だからな
現場のエンジニアや上司の指摘は通らないんだよ オレオレで作り過ぎなんよ
適当にライブラリ使うだけでええやろ >>108
「固定の独自仕様の」を抜かせば仕様書として十分
詐欺にもならんしアホは分かった気になれる >>110
それわ当たり前
仕様書下ろした連中の責任 >>36
むしろ中進国の方が高いまである
低コストハイリターンだからな
北朝鮮が国ぐるみでハッカー養成してるのと同じ クライアントから仕様が上がってくる→閏年に関しての記載が無い→気がついたけど指摘すると工程が増えるし、金も貰えない→黙っとこw
閏年に問題が起きたら起きたで仕様書に書いてなかったということで無問題&修正料金でガッポリw >>109
それじゃあ10年しか持たない。
年を4割って割り切れたら、うるう年だ。
これで俺が生きてる間は大丈夫。
というコードはいっぱい書いた 日付算出判定関数はあったけど中身作り忘れたみたいな感じかもな >>21
y2kは結構対応したよ
事前にパッチ適応した会社とか組織多かった >>115
ライブラリがいくらエラーハンドリングできてたって
実装側がエラー発生時の動作を定義してなきゃ意味がない 今の高級言語だと標準でうるう年に対応してる日付を扱うデータ型が存在していて何も考えずに作っても間違えようがなさそうなものだがなあ >>110
そうだよ
安く上げようとしてそういうやつを選ぶんだからしょうがないよね そういや昔に作ったな
Webにカレンダー表示して職場のちょっとしたスケジュール調整に使う簡単な奴
作ってみたらうるう年が無いじゃんって突っ込まれて後から付け足した ITに優秀な人材が集まる国が発展するんだよ
日本が終わったからこうなったのではなく
こうなったから日本が衰退し始めた 気づいてた末端のプログラマとかいただろうけど相手側がわかってないとか仕様書にないとかでスルーしたんだろうなぁ
納期優先遅れは許さない発注側だとわかっててもスルーする受注側もあるだろ >>17
うるう年用の処理の設計見落とし
しちった🥹テヘヘ… >>18
実際にズレてるんじゃねえかな
暑さは秋まで食い込んでるし、寒さは夏まで食い込んでる
実際、うるう年の計算は間違ってるしな 開発中に気づいたとしても伝えたら仕事増えてなぜか仕様変更の分の費用発生しないからな
そりゃやんねぇよ >>21
Y2Kの時は、何年も前から騒いでたのに
うるう年は、2/29当日になるまで気付かなかった間抜けか?っていうね
システムにもカレンダー機能とか付いてなかったんかな
そしたら誰かが「あっ、2/29が無い!」って気付きそうなもんだけど 儲けのために自社社員を辞めさせて仕様も細かく作らず下請けに安く発注してるからこうなる カレンダー自力で生成してた昔ならまだしも今はライブラリあるだろ
道具は正しく使え プログラミング言語が閏年の対応を持ってるってレスが何個かあるけど何をしてくれるの?
日付型クラスのバリデーションが閏年の考慮をしている(閏年なら2/29でもOK、それ以外ならNG)だけじゃないってこと? 過去の29日がないからエラーとかさー
流石にテスト不足としか そもそも閏年自体しらないんじゃね?
その辺のWebプログラミングスクール出ました!!的な情報系の基本的な知識0の集まりが作ってたりして これは試練だな
構築が終わったあとにメンバー全員を解散させちゃ駄目という教訓
保守メンバーには高い金を払って見てもらえ 自作ライブラリか?
4年ごとにズレていくポンコツライブラリなんかないだろうし >>141
例えば翌月とか前月の日付を取得する機能がライブラリに存在して
2024/2/29の12ヶ月前を算出させたら2023/2/28が返ってくる >>140
本当にそうだわ
実は俺の会社も障害起きたけど、既存のうるう年用の部品を使わず新しく作ったから起きた
もちろんうるう年自体は想定してたけど、うるう年当日に本日日付に起因する計算プログラムが全部コケた >>141
日付なんて固定なんだから実数値で数百年分割当とけば善くね
メモリ1MBの時代じゃ無いんだし 他人事じゃなくて胃もたれする
要件出し&基本設計あたりで延々グズグズしていて、実装以降、特にテストケースを作る・煮詰める工数がガリガリ削られる事はよくある 4年に1度の必ず起こる例外なんて割と集中的にテストする部分だと思うだがやってる感なんか 去年の2/29のデータ参照して存在しない日付だから落ちるとかなだろうけどライブラリが勝手に3/1に補正するもんじゃねえのか? >>110
そら現場でコーディングさせてる人なんか単価50万くらいの素人に毛が生えたレベル使ってるからしょうがない >>155
前回のテストは うるう年通ったので今回テストしなくてもヨシ! >>155
そんな単純な話じゃないよ
外部接続機関も揃って結合試験を行わないと発見できない
身内だけならともかく追加コスト(外部機関を動かす場合はめっちゃ高い)を払って訓練日を設けるのは普通のシステムじゃ無理
まず、客が払いたがらない
君が書いてる通り「なんでうるう年ごときシステム対応できないの?」って経営層もみんなまず思うもんね 2月29日をうるう年って呼ぶの納得いかない
うるう日の呼称をもっと広めていこう >>98
100年コピーして同じシステム使う割合なんてゼロじゃね >>85
1年前を単純に年-1に決め打ちしたんかな?
で、(2024-1)年2月29日がないからデータベース?からエラーが返ってくる >>145
なるほど、巧妙な罠だな
自分を首にしたら修正不可能なコードにしておくわけだ 日付を紐づけるシステムで閏年設定してないってどういうことだよ
あたまおかしいだろ >>12
前年同日比かー
2月29日はどうすんのが正解なんだろねw
ていうかその機能いるの? 特に運転免許証とかで 普通のDATE型使ってたら考慮されてね?
逆にどうやったらエラーになるんだ? 無駄に決め打ちしたコード書くからだよ
想像力足りないバカしかいない 日曜プログラマーの俺でも
そんなミスしねえけどな頭ピーマン人間多いな n次請けの経験の浅いZ世代新人とかに任されるような処理な気がするから個人の責任やね!
ベテランがチェックしなかったのも悪い! >>168
仕様書に記載してない上に検収してしまったんじゃ
受け入れ側の責任 実際には会社を辞めさせられる奴が腹いせでそういうコードを書いたとしか思えんな 新しいシステムなら汎用ライブラリとか使ってそうなのに
うるう年の考慮なんて初歩の初歩だと思うんだがな
設計、実装、テストの全てで見逃すとかどうなってんだよ 日本独自のバグか
顧客にあわせて細部まで作り込むから既存のライブラリは使えない
日本の文化が生み出したバグ ランダムなら対応難しいだろうけど
これは必ず4年に1回2月末に発生するってすごく簡単な仕組みじゃんね 今から365日前、という指定ならエラー出ないだろうけど、
2年前の同じ日付、と指定したらそりゃエラーになるでしょう
テストを軽視してるからな日本は >>183
2月29日は世界共通だわwww
トラブったのは4県の運転免許だけだから残りの43都道府県はちゃんとバグなくやったんだろ 何をどうしたらエラーになるのやら
他の月は29日を受け付けているのに
1日前1日後とかならうるう年は意識するしかないし >>2
そういやスギ薬局って初期のコロナワクチンで不正しようとしてたよな
西尾市も悪いけど
「スギ薬局」HD会長夫妻のワクチン接種予約に市が便宜、報道機関の指摘で取り消す
www.yomiuri.co.jp/national/20210511-OYT1T50130/ >>187
日本以外では既存のライブラリ使うからあまり問題にならない
日本は仕事しすぎてバグまで増やしてしまう 凄く古いシステムで4年に一回手動でパッチまわしてたのを忘れたとかならまだジャップやなあで済むけど
3年前に納品でこれは会社畳むレベルだろ >>52
エラー処理入れすぎるのも考えものだな
まぁこれに関してはライブラリ使えってだけだけど DATE型は内部データがミリ秒まで持ってたりするからそこんとこ理解してないと比較演算子使うと予期せぬ結果が戻るんだよね
だから日付は文字列で扱う場合が多い うちの会社でも今朝「昨日(2/29)のデータがないの!!」って大騒ぎしてた ただ今回のケースは2/29に前年日データは無いんだから何も取ってこないが正解だと思うんだよ
ライブラリ使ったらそれっぽい誤った値を取ってくるからそれはそれでマズくないか
面倒臭いなあ、前年日データいるか? >>185
pythonのrelativedelta(years=1)で1年前出力したら
2月29日の1年前は2月28日
2月28日の1年前も2月28日
になったわwww
正解がなんなのかは難しい話ではあるけども、少なくとも不具合(エラー落ちしたり)は起こすなやって話だわな >>191
やってる感の為には車輪の再発明も厭わない >>92
ゥ (⌒─⌒) ゥ,、
ゥ'`((´^ω^)) ゥ
'` / つと) '`
しー-J 毎年 単純ミスにより
何度のシステム障害を起こしてるのか
携帯も然り
トンネルの厚さも然り 仕様にあるとかないとか以前の問題
日付カレンダーはシステム仕様より上位の概念だから、無条件にうるう年は実装しなければならない 最後まで読み取らせずにそのまま袋に入れて会計が
えぇ… 免許証だと「~年まで有効」の計算でしくじったのかね
元号で出さないといけないからdate関数使えなくて自前の関数使ったとか >>209
それ思ったけど、有効期限は誕生日が基準で更新に行った日は関係無いよね?
昨日一斉に起こったってのは免許の有効期限は関係無いと思う 相変わらず日本のIT産業は劣悪
公金チューチューだけはナントカ重工など財閥系斜陽産業なみにイッチョマエ カレンダー機能を1から実装とか無駄すぎる
くだらない 昔自前計算で作ってたアホのせいで障害対応やらされたわ 2000年問題ならまだしも4年に1回のものにすら対応できないのはちょっと うちの一年前にリリースしたシステムでも絶賛トラブってるわw バレてないだけで今日(3/1)の前日を2/28としてるシステムとかもあったりしてwww 限界値検査なんて昔むかーし情報処理技術者試験で勉強したもんだ☺ 春分の日と秋分の日を自動計算しろと言われたことはあるな
よくわからんからできないと断ったが >>141
例えばEXCEL(厳密にはプログラミング言語じゃないかもしれないが)だと日付は内部的にはただの実数値(浮動小数点数型)として持ってる
具体的には1を1日として1900/1/1 0:00からの経過時間で日付を計算している
例えばDATE(2024,3,1) - 2で計算するとちゃんとうるう年を考慮して2024/3/1の2日前の2024/2/28の日付が結果として表示される コンピュータすらない時代に作った法律ですら「前日の24時」とかいう記法使ってイレギュラーを排除したというのに 日付と時間はプログラムの中でもトップクラスに厄介な代物なのに何故考えが至らないのか >>36
バカにしてんじゃねーよ中進国を😡
真面目な話IT頑張らなくても手作業もの作りでも食ってけたって企業の怠惰さと勉強したくない日本人の怠惰さが相まって新陳代謝が進まなかったからITやらなきゃ儲からないって最初から取り組んでる中進国企業より遅れる >>210
確かに
他に計算の必要性あるとしたら更新期限内(誕生日前後一ヶ月以内?)かどうかの判定とかかな >>217
そのわりに嫌儲にいるエンジニアとやらってやたら態度がデカくない? >>231
ジャップだからね
虚勢を張るしかできることないのよ 中抜き酷すぎてそんなん分かってても言いたくないような現場ならありえそう うるう年なんて何回もあったのに、
ニュースになるほど頻発するのは記憶にないな こういうのは大抵営業日とかを設定してるマスタとかに不備がある
システムの欠陥というよりは人為ミス >>11
言われたことしかやらない会社や人間はどんどん淘汰されればいいと思う だって実際に作業してるのは手取り15万以下の連中だぞ 全員誰かがなんとかするだろって思ってる
途上国の人間の思考法 たかが免許に県毎のシステムなんて必要なのか?
全国統一しろよ エンジニアの怠慢というより上がテストを軽く見て充分な予算振ってないんじゃないかな >>231
嫌儲で態度デカくないヤツのほうが珍しい
まあXでもパソコンの大先生みたいなのは大体デカい 止まる日までは大勝利で連勝街道なんだよ
スラップ訴訟みたいなもん >>133
ユーザーインターフェイスとは関係ないから内部仕様だろ
お前は外部仕様はどういうものだと考えてる? >>11
社会通念上常識だったりほぼ当たり前の仕様はベンダー側が確認して作らなきゃいけないという判例があるみたい。今日記事読んだ。 >>224
2038年問題のこと?
あれは2000年問題と違ってアプリケーションレベルで解決できないからきつそうだよなぁ
アメリカですらリスク高のままだから日本はまず何かしら起こると思うわ。ありがちなのがATM停止だな。絶対にレガシーなまま行くシステムだから >>236
システム開発は言われた事以外やっちゃいかんのだ 集計期間のCSVを23年を24年に置換してコピーしてと...
start,end
2024‐01-01T00:00:00+09:00,2024‐01-31T24:59:59+09:00
2024‐02-01T00:00:00+09:00,2024‐02-28T24:59:59+09:00
2024‐03-01T00:00:00+09:00,2024‐03-31T24:59:59+09:00
:
ヨシ! 基本情報でうるう年を計算する問題はあるな
他のアルゴリズムよりましだけどめんどくさいな >>9
経験がないだけな
新卒じゃなくておっさんでも未経験で採用したらそうなる >>244
コロナ前はうるう年のテストを各段階でやってたけど
コロナ以降予算減って
うるう年はいいか~って雰囲気になって今、爆発してる 大人しくfreeeでも使っとけよ
AWS構築するような時代遅れのシステム今更構築してんじゃねーよ 嘘でしょ?日付の計算を自前でやるの?
OSとかないの >>50
そこで2400年もうっかり除外してバグを埋め込まないとw
100年後でもいいからシステム開発がどうなってるのか見てみたいわ 2月は28日までなんて定義したコードは書かないと思うけどな コーティングするのは末端のやっつけ仕事する外国人だしシステム開発知らない人は現実を知らなさ過ぎる
建設とかだとドカタってすぐわかるが 2000年問題のときに話題になった閏年の例外処理ならともかく閏年を入れ忘れるのは無能すぎる 前に同僚でうるう年のバグ出した人は
年関係なく月日のみの大小関係を比較しようとして、日付すべての年を9999にして比較→うるう年で例外とかだった
まあ、やりたいことはわかる カレンダー作成はプログラミングの基本だろ
パイソンしかやってないから基本が出来ないんだろ >>11
これあるよな
下手な職場だとなんか言うと個人の責任にされてあれもこれもやらされるし なぜか日付ライブラリ使わずに自前組み立てで加算とかする勢力おるよな >>220
漠然とした要求ではモノ作れませんでええんやで 閏年をどう扱うかはビジネス側の要件だからな
例えば売上を前年と比較して日次でグラフ化したいなら、
前年の28日と比較する
前日の28日に含めて前年と比較する
前年データなしとして0と比較する
29日の売上を28分割して2月の各日に振り分ける
みたいに、どう処理して欲しいか要件定義で決めてくれなきゃ例外処理としてエラー出すしかない 裁判だとベンダーは要求が曖昧だったり誤ってたりする場合はアドバイスする義務があるって判決が出てる
ベンダーは仕様通りに作るのが仕事ではなく
ユーザの抱える問題を解決するのが仕事
だから要件、要求が素人丸出しなら支えろとのこと >>266
グレゴリオ暦だと、4で割れる年は閏年→例外で100で割れる年は平年→例外の例外で400で割れる年は閏年
だっけ
処理面倒くさそう 昔のスタンドアロンのシステムなら日付ちょっとかえて閏年テストとかやってたけどね
今はテスト環境でもサーバーの日付弄るのは難しいのか? >>266
2000年問題に閏年は関係ないが
400の倍数だから閏年から除外される例外側ではないし >>275
そんなもん元請けの仕事だろ
俺が知るか >>277
処理的には400→100→4で判定するだけじゃね? >>277
上から順に
400で割れたらreturn true
100で割れたらreturn false
4 で割れたらreturn true
ここまで来たら無条件にreturn false
てやるだけ ていうかカレンダーなんてオープンソースの使えばええがな プログラミングよく知らんけど日付関係の処理なんていちいち自分で計算部分まで作るもんなん? 2~3ヶ月くらい会社で独学させた奴を現場に放り込むのが普通の業界
まともなもんが出来るわけない 昔のシステムはカレンダーを内部で作成するんよ
COBOLとかよくある手法らしく
カレンダー先に作るから、29日を作る処理が抜けてるとおよく起きるみたい
今までそうしてた?かというと手動でカレンダーのテーブルに追加してたとか聞く 毎年祝日の配置が変わるの知らんのか?
そして追加も廃止もある
あらかじめ用意できるものじゃない 上の方が物事決める詰め甘くても下が気を利かせてなんとかする時代では無くなったから、
上が色々な特殊処理必要な時の仕様まで決めないとね 20年以上様々なシステムに関わってきたけどうるう年バグなんて見たことないぞ 2/29から1年を引いたら何日なるの?普通に2/28か3/1で処理されるのかと思ったわ
2023/2/29の文字列を変換しようとして例外エラーなったとかそんなアホな事してんのか? マジでうるう年トラブルだったのかよ
うるう年って別に最近始まったシステムじゃないのに 請負先から会計にトラブルがあって月末支払いが10日前後になりますと謝罪があったけど原因これかー システム屋だけど何やらかしたらこんなことになるのかわからない
前年当日のデータを見てるとかなのかな >>294
仕様決めてるやつに「一年を引く」の定義を確認しなければならない うるう年を考慮しないシステムって凄いな、原始人か? 後付けで追加した機能に閏年判定が仕様から抜けてたのかね >>294
2/29わ幅のある時間帯だから1年は引け無い
はい論破😤 C#で2/29をAddYear(-1)すると2/28になるよね確か Date型使えば自動的にうるう年考慮してくれるだろうにどういうミスなんだろう 100年に一度閏年がなくなって400年に一度なくなるはずの閏年がなくならない、ここまでシステムに組み込むべきだろ 上から下まで全員が閏年を知らないんだな
テレビ局みたいだな 俺のチプカシF-91W(ビンラディンモデル)も昨日3月1日になってたわ 指摘して得られるインセンティブが追加労働と問題おきた時の責任だから指摘せずにそのまま通すのが当然になる >>268
だろうね
プログラマーでもエンジニアでもない
パイソンライブラリオペレーター >>268
Python使ってるなら日付は最初から最後までdatetime型を扱うライブラリに一貫して任せっきりにしておけば閏年で不具合なんか出ないと思う 4で割りきれる年は閏年だけど、100でも割りきれる年は閏年じゃないけど、400でも割りきれる年はやっぱり閏年 >>20
👨「ライブラリとかにうるう年判定とかあるやろ」
🤖「え?」
👨「え?」 JSON形式で作ったよ。使ってね。
{2068,2064,2060,2056,2052,2048,2044,2040,2036,2032,2028,2024} カレンダー自前で持ってるプログラムなんてあるのか
ああいうのってなんか標準のやつを参照してそうだけど 情報処理界隈って自分で作れ精神だからこういうことになる 想定してたに決まってるだろ馬鹿か貴様ら低能が
複雑なシステム(エクセルのハイパーリンク)が絡んで想定外の事象が発生したんだよ多分 過去一年の処方箋歴とか参照したかったのかな?
それでただ単純にyearを-1したと
普通にDATE関数使ってれば良いけど
人が理解しやすいように年だけ別カラムのデータベース組んでた感じか スギ薬局も何で契約したの?
実績のあるソフトの方が良いだろうに これさ太陽フレアだか地殻変動だかで今も地球の周回周期もコロコロ変ってるんだろ?スクラップビルドするしかないんよ >>328
こいつ等何なら出来んだ?
何やらしてもパッとしないゾンビみたいな会社 夏季オリンピック=閏年をトキョがぶち壊したから。。。 糞ワロタ
そんなギャグマンガみたいなことあるんか
その昔、2000年問題ってのがあったが >>236
言われたこと以外やっちゃだめ
要求仕様は絶対 神奈川の免許センターもNECだよな
免許更新しようとしたらNECの機械が非対応で引いた
赤ちゃん名前ランキング上位にも入ってる漢字なのに… 経験あるフリーランスの方が大企業の寄せ集めよりちゃんとしたものつくるし見積もりも大幅に安くできるよ 日付計算くらいどんなフレームワークにもあるだろ
何使って計算してたんだよ >>275
それはあくまで発注書の質を高める、もしくは追加依頼に関する話で、検収のスキルの低さを補う話ではない
自力で検収できないならコンサルでも何でも使え発注者としての責任を負えが結論 1年前の同日の情報を取得しようとして
(何に使うのかは知らん)
2024/02/28→2023/02/28
2024/02/29→??????
2024/03/01→2023/03/01
こうなった
この閏日の例外をどうするか設計で決めていなかったという話 NECの凋落は酷いな…
バリュースターのころは好きだったぞ >>342
バリュースターの時点でもうアメリカ製PCの方がコスパ上だったし 20240229と20230229の比較て
そんな日存在せんわ!
エラーになったということ?
365日前と比較するようにしていれば20230228との比較なら問題なかったということ? 100年以上前の明治時代からグレゴリオ暦使ってるのにうるう年知りませんでしたはちょっと話通らない ■ このスレッドは過去ログ倉庫に格納されています