IConvertible要するに、問題があります。実装されていれば、DateTimeOffset問題IConvertibleは発生しません。
拡張メソッドを使用してインターフェイスを実装することはできないため、道路は閉鎖されています。構造体DateTimeOffsetは部分的ではないため、そのように拡張することはできません。
いくつかのMSDNドキュメントを読んでいると、TypeCode列挙型に出くわしました。これは、IConvertibleが正しく機能するために必要なようです。そして、私の残念なことに、列挙型にはTimeSpanも含まれていませんでした。これにより、and (ie = P)Tupleで-like構造を使用するオプションが閉じられます。DateTimeTimeSpanDateTimeOffset
私の質問は次のとおりです。基本的なIConvertibleまたは同様のサポートがあるDateTimeOffsetと同等のものをどのように実装しますか?
実装は、[index,TType] where TType : IConvertible(セッター、ゲッター、トライゲッターの両方の)機能を備えた派手な怠惰な辞書の実装に関するものであり、タイムゾーン固有のデータを格納できる必要があります。
これまでの私の考え:
ISuperConvertible実際には単なる拡張である新しいインターフェースを作成し、特別な場合IConvertibleを作成します。DateTimeOffsetこれにより、IConvertibleのサポートは一般的に機能しなくなりますが、この非常に特殊なケースでは機能します。長所と短所?DateTimeOffsetsを格納するために2つの「スロット」を使用します。1つはと30分オフセットDateTime用ですint(すべてのタイムゾーンは1時間ではありません= /)。その後、機能が失われcache[ApplicationStrings.LastUpdate, default : DateTimeOffset.Min]ます。
それらは私の主な考えを表しています。つまり、ブレークDateTimeOffsetアンドキープIConvertibleまたはブレークIConvertibleアンドキープDateTimeOffsetです。
私はまだC#の本質的な特性に慣れていないので、どんな洞察も役に立ちます。あなたの考えは何ですか?
編集:追加:
- 現在、DateTime(固定タイムゾーン)を使用する実用的なソリューションがありますが、タイムゾーンも必要です。最適なシナリオは、代わりにどこでもDateTimeOffsetを使用することです。本質的に問題はリファクタリングではありませんが、私の特定の問題はです。
- これは非常に大規模なアプリケーションであり、さまざまなサービスやストレージと通信するためにエンティティフレームワークやその他のよりあいまいなフレームワークを使用します。したがって、単純なシステム定義タイプを維持しても、LINQ-to-Xの最適化などが損なわれることはありません(これらがどれほど難しいかはわかりません)自分でやることです)。
- 別の人がいつやって来て、タイムスタンプに使用されるDateTimeがあることに気づき、オフセット(タイムゾーン)を考慮せずにそれを使用するのかわからないため、データの分割には反対です。