前任者から引き継いだシステム、うるう年なのに何故か2/29が表示されないと思ったらとんでもない設計になっていた件 - Togetter
単純に否定もできんけどな。2000年までしか使わず、且つ閏年そのものの計算をする必要がない（西暦から判定出来れば良い）のであれば別に問題ない。そもそも言語によっては日付計算や和暦計算バグもあったわけでして
正直、内容からなぜ2月29日だけを表示する仕組みが必要なのかがさっぱりわからないので、なんとも言えないが、少なくとも閏年であるかどうかを判定するのであれば、計算ロジックをくんでも良いし、別にハードコーディングでも実際は問題ない。
1992年以前に組まれたコードであればまずネット系であればPerlやそれ以前（CGIを多用している時代）であり、その頃のサーバはまず大規模計算（ここでいう大規模計算とは、極論言えば数十件のテーブルを再帰的に計算するだけで破綻する程度の事）はできないわけで、例えば単純に閏年という事を判定したいだければあればおそらく私も計算等しない。
当時はね。
メモリがビットレベルしか無いときは、そういった時代の計算ロジックが必要で、今のあり方で判断するのは間違い。
なお、1992年がどのような時代であったかというとだいたいISDNへの切替えすらまだ大規模には始まっておらず、56Kモデムが比較的高速な部類で、おそらきは28.8K当たりが主流で、一部は33.6Kモデムあたりを使っている時代だ。
レンタルサーバで言えば、おそらく国内でも使える容量は数Mバイトで百Mバイト以上の容量なんて大容量すぎてむしろ何に使うのかというレベルだたっと思う。
閏年は計算して算出するのが当然、と思うだろうが、20年も昔のサーバでは何でも計算はできない。
例えばデータベースもデータを詰めこんではならなかった（高速稼働するための条件を満たす前に現金が高速で溶けるので）時代で、メモリの限界や使えるCPU時間（今の人にはわからないだろうが、CPUは独占できないもので、計算時間は皆が分割していたのだよ）には限りがあった時代であって、そうなると「やらない事」を決めるのはむしろ技術が必要ではあった。
そもそも2月29日だけが表示されないという事であれば、カレンダーのようなものを表示する仕組みであったとして、1月から12月までを定型化した構造で管理した上で、例外の閏年の場合だけ2月29日を追加するというものだろうか。
そんな事をする意味はないのだが、仮にそういった処理があったとして、この場合、カレンダーの表示をするおおもとの仕組みが破綻しているので閏年の話しよりもエンジニアであればそっちに驚愕するのが普通だと思う。
カレンダーのような日付を表示する場合、極論言えば、表示される日付は設定による。
サーバ設定なのか、昔であればクライアント側の設定を参照する事もあった（今と違い、昔は無尽蔵な通信が使えなかったので日時を常に同期をとるよりも、場合によってはクライアントの時刻を利用するような仕組みもあった／場合によるけどね）わけで、つまりはいつを表示するかなんてのはわからない。
未来かもしれないし、はたまた過去かもしれない。
だとするとそもそも稼働期間が特定される前提であることが問題なわけで、その場合、閏年がどうという話しでもない。
単純に目につくアウトプットが閏年だったというだけであり、おそらく構造上、そもそも未来や過去を想定していないというのが問題で、エンジニアとしてはそれが本質的な問題であり、その枝葉の一つが閏年であったというだけの事で、本来「凄くやばい実装」という話しはそちらの議論になるわけなのだが･･･。
仮に、実装が1996年頃で、前後5年程度を想定している、とするなら実はこのシステムは全く問題がない。
1992年は表示できるし、2000年も表示出来ているわけで、その上計算量も最小で、実際は日付を計算する必要がないのであれば、特段の問題はない。
が、できればもう少しバッファーはもって欲しい所ではあるが。
なお「計算なんて標準関数やライブラリを使えばロジックすら知る必要がない」等というアホはイチから勉強し直す事とお勧めする。
多くの言語で日付計算にはバグがあったし、ライブラリであれば仮に日付計算にバグはなくとも設定よってはバグとなることは多々ある。
例えば、計算基準がUTCなのにそれを理解しないままJSTで突っ込んで日付計算しているような糞コードは、正直閏年を手打ちするよりも糞コードだし、意味もわからずに使うんじゃねーよと。だいたいそういったコードはデータベース内の日付フィールドの定義から間違っている為、保存されているデータからクレンジングが必要で大抵詰んでいる。
なので、閏年という判定がなぜ必要なのか、それは日付として算出する必要があるのか、その日付はローケーションを限定できるのかどうか、そしてその上でそれはどのような目的で使われる事を意図しているのが、というような事を考えた上で、それが計算を必要としかったのであればおおよそ1992年頃から数年であれば別に絶望的なものでもない。
というか、よりわからんのはCOBOLや一部の言語を除くと、2000年を超えてもなんらリビルドしない仕組みという事の方が問題だと思う。
大抵は2000年頃にチェックしているし、その時点で問題があれば別に2000年が到来する以前にその問題には気づいており「ああ、これはマズいね」という事で普通に対処されていたものでしかない。
実際2000年に対応していたのであれば、別に問題もなにもない。
が「でなかったので」とあるわけですから、少なくとも2000年以前にはチェックしていないのか、またはチェックした人が見落としたという話しであって、誰に責任があるのかというと非常に微妙。
例えば2000年問題に対応するために、全データと日付計算ロジックを全て刷新して、永続的に利用出来る仕組みに対応しろ、半年で、なんて依頼は対応できないから、当時は取り急ぎ2000年が到来しても影響しないようにして欲しい、その後時間をかけて次のシステムに移行するので、なんて話しは吐き捨てる程あった。
という話しも考えれば、一番ヤバいのは、どう考えても2000年頃にまともなチェックをしていない体制や企業であって、その後それが問題を起こすまでだれもメンテしていないという事が問題だと思うのだが。
なんというか、この話しで閏年の判定についてキャッキャしている人というのは、本質的には閏年をハードコードするような事と同じ思考回路ではないかと思わなくはない。
そういう話しだと思う。
