Microsoftは、日付の計算におけるソフトウェアエラー（うるう年以上）が先週、WindowsAzureの大規模な停止を引き起こしたと発表しました。
DateTime.Now.AddYears(1)うるう年を回避するための判断の単純な誤りでしたか？
どのようなコーディング慣行がこれを防ぐことができたでしょうか？
編集
うるう年でdcstrawが指摘したようDateTime.Now.AddYears(1)に、実際には.NETで正しい日付が返されます。したがって、これはフレームワークのバグではありませんが、明らかに日付計算のバグです。
回答:
恥知らずなプラグ：
より良い日付と時刻のAPIを使用する
組み込みの.NET日付と時刻ライブラリを適切に使用するのは非常に困難です。彼らはない、あなたが必要なすべてをやらせる、しかし、あなたがすることができない表現型システムを通じて明確に自分自身を。DateTime混乱で、DateTimeOffsetあなたはあなたがいないとき、実際にタイムゾーン情報を保存している、と考えることにあなたを小康状態かもしれTimeZoneInfoあなたが考慮されるべきであるすべてのものを考えるようにあなたを強制するものではありません。
これらはいずれも、「時刻だけ」または「日付だけ」を適切に表現するものではなく、「現地時間」と「特定のタイムゾーンの時間」を明確に区別するものでもありません。また、グレゴリオ暦以外のカレンダーを使用する場合は、Calendarクラス全体を受講する必要があります。
これらすべてが、私がNoda Timeを構築している理由です。これは、Joda Timeの「エンジン」のポート上に構築された代替の日付と時刻のライブラリですが、新しい（よりスリムな）APIが上部にあります。
あなたが考えたいと思うかもしれないいくつかのポイント、あなたがそれらに気づいていないなら見逃しがちです：
TimeZoneInfo率直に言って、一般的に明らかにすることをいとわない以上のものです。（「標準時間」の概念が時間の経過とともに変化する、または恒久的な夏時間になるタイムゾーンはサポートされていません。）特定の開発慣行に関する限り：
DateTime.Nowまたはを明示的に呼び出すのではなく、「時計のようなインターフェイス」（現在の時刻を通知するサービス）をDateTime.UtcNow挿入することをお勧めします。ユニットテストが簡単になります（実行可能です！）バグはおそらくあなたが投稿したような行によるものではなかったことは注目に値します：
DateTime.Now.AddYears(1)
無効な日付は作成されません。実行する場合：
(new DateTime(2012, 2, 29)).AddYears(1)
2013年2月28日を取得します。Azureのゲストエージェントが何で記述されているかはわかりませんが、別の呼び出しが失敗したに違いありません。.NETでこれを行うための悪い方法は次のとおりです。
new DateTime(today.Year + 1, today.Month, today.Day)
todayうるう日であれば例外をスローします。ただし、Azureの問題に関するMicrosoftのブログでは、2013年2月29日の無効な日付が作成されたと述べていDateTimeます。これは、.NETで実行できるかどうかはわかりません。
私はそれを言っているわけDateTimeでDateTimeOffsetはなく、エラーが発生しやすいわけでもありません。ただ、彼らがこの特定の問題を引き起こしたとは思わないだけです。
うるう年のバグから保護するように設計されたコーディング手法をどのように開発できますか？どのようなコーディング慣行がこれを防ぐことができたでしょうか？
ジョンが述べたように、特定の日付の単体テストは、役立つ1つのコードプラクティスですが、私が「手動統合テスト」として定義したものに勝るものはありません。
開発/テストベッドサーバーの時計を変更し、時間が経過したときに何が起こるかを監視します。
これが「コーディングの慣行」であるかどうかの詳細にとらわれないでください-明らかに、カレンダーのすべての日付に対してこれを行うことはできません-関心のある日付を選択してください。2月29日は月末です。日付または夏時間の切り替え日。