アカウント名:
パスワード:
ITスタッフの9割はスキル不足 [srad.jp]# スタージョンの法則の特殊例にすぎないよな
Excelも使いこなせないMS技術者？
クラスターの拡張は自動的にやっているのかと思いきや中の人がExcelで有効期限計算したりしてたのか…。正直そっちのほうが障害そのものよりはるかに恐ろしい
いやいや、むしろExcelだったら問題なく処理してくれます。
A1に2012/2/29と入力しておいて、適当なセルに=DATE(YEAR(A1)+1,MONTH(A1),DAY(A1))などと。
Excelは間違えなくても人間が手動でやってたらミスるのは必然でしょ。ああ日本ではミスった担当者の資質の問題にすべて帰着されるんだっけ。(そしてミスはいつまでたってもなくならない)。
いつまでたってもなくならないのであればそれはミスではありません。それは仕様です！
方眼紙として便利に使ってます
こんな典型的な「『車輪の再発明』の連鎖」が、21世紀になってもまだ解決されてないとか、もうね…。
DateTime d = new DateTime(2012, 2, 29);Console.WriteLine(d);Console.WriteLine(d.AddDays(365));Console.WriteLine(d.AddYears(1));
ふつーに書けばふつーに正しく計算するのだけど、やっぱり車輪の再発明をしていたのだろうね。
DateTime d = new DateTime(2012 + 1, 2, 29);これで例外をcatchしてなかったんじゃね?
2012/1/1〜2/28に呼ばれることも考慮する必要があるから、
Console.WriteLine(d.AddDays(365));
は、1年を満たさないという例？
$d =`date -d "2012-02-29 1year" "+%Y-%m-%d"`;これは「ふつー」じゃない？
月末日を求めるのに、一生懸命条件分岐で処理するコードって、困った事によく見かけるんですよね・・・
# 月が1,3,5,7,8,10,12は31、2は年を4で割った余りが（以下略）なんてifの羅列が
年、月、日とシリアル値の相互変換ができる言語なら、[翌月1日]－[1日]でいいじゃんと思いつつスルーしていますが。
> [翌月1日]－[1日]でいいじゃんそして翌月を求めるところで単に月に1を足してバグると。
日付型使っても[翌月1日]のところを「1日を求める」→「翌月を求める」の順に処理しないとバグることがあるよ(日付型の仕様にもよるが)。「こんな簡単なことも…」とか言ってる奴に限ってこんな簡単なことをミスる。
今回の問題とは直接関係ないですけど、いわゆる日付型で、『2012年2月29日の1年後』を取得すると、たぶん『2013年2月28日』か『2013年3月1日』か『日付取得エラー』になると思うんですけども。これはこれで何かのトラブルの元になりそうな気もする……
＃手近にあったPostgreSQLだと2013-2-28を返してきた。他の環境ではどうなんだろう。
日本の民法準拠なら「2013年2月28日」となるのが正解ですね。
「民法準拠ならば」ですね。でも、サービスの期間にこれを適用すると、初日不算入やら「1年間有効って言ったじゃねーか」とクレームの嵐になる予感．したがって、対応する暦日がない場合や休日に当る場合は、翌日にするのが無難でしょう。
#この間Symantecの有効期間最終日にLiveUpdateしようとしたら、延長権買わないとだめだと曰いやがった。あれもこれ絡みか？
C#だと、2012/2/28と2012/2/29の1年後は2013/2/28でした。当然といえば当然ですが、2/28の1年後と365日後はちがいました。
『2012年2月29日の365日後』を取得すれば良いのでは？（1日のズレが累積するのは仕様です！）
2012年2月28日の1年後が2013年2月27日になるのか。それが原因で障害起こしたら背比べしてるどんぐりからボロクソに言われること間違いないね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
なんという・・ (スコア:1)
日付型すら使っていないとか、予想よりはるかに低レベルで驚いた。
Re: (スコア:0)
ITスタッフの9割はスキル不足 [srad.jp]
# スタージョンの法則の特殊例にすぎないよな
Re: (スコア:0)
Excelも使いこなせないMS技術者？
Re: (スコア:0)
クラスターの拡張は自動的にやっているのかと思いきや中の人がExcelで有効期限計算したりしてたのか…。
正直そっちのほうが障害そのものよりはるかに恐ろしい
Re: (スコア:0)
いやいや、むしろExcelだったら問題なく処理してくれます。
A1に2012/2/29と入力しておいて、適当なセルに=DATE(YEAR(A1)+1,MONTH(A1),DAY(A1))などと。
Re: (スコア:0)
Excelは間違えなくても人間が手動でやってたらミスるのは必然でしょ。
ああ日本ではミスった担当者の資質の問題にすべて帰着されるんだっけ。(そしてミスはいつまでたってもなくならない)。
Re:なんという・・ (スコア:1)
いつまでたってもなくならないのであればそれはミスではありません。
それは仕様です！
Re: (スコア:0)
方眼紙として便利に使ってます
Re: (スコア:0)
こんな典型的な「『車輪の再発明』の連鎖」が、21世紀になってもまだ解決されてないとか、もうね…。
Re:なんという・・ (スコア:2)
DateTime d = new DateTime(2012, 2, 29);
Console.WriteLine(d);
Console.WriteLine(d.AddDays(365));
Console.WriteLine(d.AddYears(1));
ふつーに書けばふつーに正しく計算するのだけど、やっぱり車輪の再発明をしていたのだろうね。
Re: (スコア:0)
DateTime d = new DateTime(2012 + 1, 2, 29);
これで例外をcatchしてなかったんじゃね?
Re: (スコア:0)
2012/1/1〜2/28に呼ばれることも考慮する必要があるから、
Console.WriteLine(d.AddDays(365));
は、1年を満たさないという例？
$d =`date -d "2012-02-29 1year" "+%Y-%m-%d"`;
これは「ふつー」じゃない？
Re: (スコア:0)
月末日を求めるのに、一生懸命条件分岐で処理するコードって、困った事によく見かけるんですよね・・・
# 月が1,3,5,7,8,10,12は31、2は年を4で割った余りが（以下略）なんてifの羅列が
年、月、日とシリアル値の相互変換ができる言語なら、[翌月1日]－[1日]でいいじゃんと思いつつスルーしていますが。
Re:なんという・・ (スコア:1)
> [翌月1日]－[1日]でいいじゃん
そして翌月を求めるところで単に月に1を足してバグると。
Re: (スコア:0)
日付型使っても[翌月1日]のところを「1日を求める」→「翌月を求める」の順に処理しないとバグることがあるよ(日付型の仕様にもよるが)。
「こんな簡単なことも…」とか言ってる奴に限ってこんな簡単なことをミスる。
Re: (スコア:0)
今回の問題とは直接関係ないですけど、
いわゆる日付型で、『2012年2月29日の1年後』を取得すると、
たぶん『2013年2月28日』か『2013年3月1日』か『日付取得エラー』になると思うんですけども。
これはこれで何かのトラブルの元になりそうな気もする……
＃手近にあったPostgreSQLだと2013-2-28を返してきた。他の環境ではどうなんだろう。
Re:なんという・・ (スコア:1)
日本の民法準拠なら「2013年2月28日」となるのが正解ですね。
Re: (スコア:0)
「民法準拠ならば」ですね。でも、サービスの期間にこれを適用すると、初日不算入やら「1年間有効って言ったじゃねーか」とクレームの嵐になる予感．したがって、対応する暦日がない場合や休日に当る場合は、翌日にするのが無難でしょう。
#この間Symantecの有効期間最終日にLiveUpdateしようとしたら、延長権買わないとだめだと曰いやがった。あれもこれ絡みか？
Re:なんという・・ (スコア:1)
C#だと、2012/2/28と2012/2/29の1年後は2013/2/28でした。
当然といえば当然ですが、2/28の1年後と365日後はちがいました。
Re: (スコア:0)
『2012年2月29日の365日後』を取得すれば良いのでは？（1日のズレが累積するのは仕様です！）
Re: (スコア:0)
2012年2月28日の1年後が2013年2月27日になるのか。それが原因で障害起こしたら背比べしてるどんぐりからボロクソに言われること間違いないね。