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