3

私の最大の不満の 1 つは、平均的なユーザーが直感的に API で行うと思われることを行わない API です。

事例: .NET のDateTime.ToUniversalTime。ドキュメントは恐ろしいです：

Windows XP システムでは、ToUniversalTime メソッドは、現地時間から UTC への変換時に現在の調整規則のみを認識します。その結果、現在の調整規則が有効になる前の期間の変換は、現地時間と UTC の差を正確に反映しない場合があります。

そして後にこう続けます。

Windows XP システムでは、ToUniversalTime メソッドはローカル タイム ゾーンの現在の調整規則のみを認識し、下位レベルの日付 (つまり、現在の調整規則の開始日より前の日付) を含むすべての日付に適用されます。 . 歴史的に正確なローカル日付と時刻の計算を必要とする Windows XP で実行されているアプリケーションは、FindSystemTimeZoneById メソッドを使用してローカル タイム ゾーンに対応する TimeZoneInfo オブジェクトを取得し、その TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) メソッドを呼び出すことによって、この動作を回避する必要があります。

これは、これまでに作成されたドキュメンテーションの中で最も愉快な一文に違いありません。ToUniversalTime() を使用するときに、正確なローカル日付と時刻の計算を必要としないのは誰ですか? このメソッドを ObsoleteAttribute でマークしないのはなぜですか?

とにかく、私が探しているのは、[RequiresHistoricallyAccurateLocalDateAndTimeCalculationsAttribute] などのアセンブリ レベルのメタデータでアセンブリをマークできるツールです。次に、ToUniversalTime() のインスタンスが見つかった場合は、コンパイラ エラーとしてフラグを立てます。これは、C# でアンマネージ コードに安全でない注釈がないと直接アクセスできないのと同じ方法です。

4

2 に答える 2

3

この要件は、属性の装飾やコンパイル エラーよりも、コード分析に適しているようです。

参照: http://www.binarycoder.net/fxcop/html/index.html

これは、これまでに作成されたドキュメンテーションの中で最も愉快な一文に違いありません。ToUniversalTime() を使用するときに、正確なローカル日付と時刻の計算を必要としないのは誰ですか? このメソッドを ObsoleteAttribute でマークしないのはなぜですか?

日付/時刻計算の性質/複雑さを考えると、これは特に恐ろしい/衝撃的な啓示ではありません。

Windows XP やその他の OS で UTC 処理を行っている場合は、他のほとんどの複雑な操作と同じように、最初にプラットフォームの特異性を理解します。与えられた代替 ( TimeZoneInfo) は、プラットフォームに大きく依存するため、防弾ではありません。

のプラットフォーム依存性についてTimeZoneInfo・・・OSのことです。

タイム ゾーンの変換 (日付関連の問題の多くが発生する原因) の作業を開始するときは、FindSystemTimeZoneByIdなどのメソッドを使用します。プラス面としては、メソッド名により、ローカル システムで作業していることが明確になります (したがって、おそらく より曖昧ではありませんToUniversalTime())。ただし、OS はタイム ゾーンのリストを照会されるため、OS が不適切なリストを返す可能性があります (Windows では値がレジストリにあると思います)。 ）など

Windows XP にもあいまいな問題があるように思われることに気付きましたTimeZoneInfo(「発信者への注意事項」を参照)。

Windows XP システムでは (...) その結果、メソッドは、現在の調整ルールが有効になる前の期間のあいまいな時間オフセットを正確に報告しない場合があります。詳細については、Local プロパティの「呼び出し元に関する注意事項」セクションを参照してください。

そして (ご指摘のとおり)、基盤となるプラットフォームの実装に欠陥がある可能性があります。

さらに、タイムゾーンは文字列 ID によって参照されます。これらはあまり変わっていないように見えますが、アプリケーションに格納された「魔法の文字列」がタイムゾーンと一致しなくなる可能性がまだあります。

この件に関する私の知識は網羅的ではありませんが、少なくともそれは私が見つけたものです. Windows Server での .Net とユニバーサル タイムの使用経験は良好です。

私が言いたいのは、BCL (基本クラス ライブラリ) の作成者が特定の方法で実装したのには、たとえ予期しない動作が発生したとしても、通常は十分な理由があるということです。別の方法は、機能を完全に省略することです。

これを落とし穴だと認識しているのであれば、それを軽減するために時間を割いていることは称賛に値すると思います。

于 2012-08-14T20:15:43.790 に答える
1

FxCop ツールと友達になりましょう。私が理解していることから、これはあなたが探しているものです。これは、FxCop API に依存する C# コードとして表現されるカスタム ルールで拡張できる静的分析ツールです。

于 2012-08-14T20:15:09.007 に答える