_この問題は、開発者コミュニティのチケットから移動されまし
現在、DateTimeOffsetにはタイムゾーン変換のオプションがなく、TimeZoneInfoのWindowsAPIはDateTimeOffsetをサポートしていません。
これにより、日時オフセットを日時に変換するコードを記述し、TimeZoneInfoを使用して新しい日時に変換してからDateTimeOffsetに戻す必要があります。これにより、目的の時点とタイムゾーンが維持されます。
フォーマットと関連するAPI呼び出しの間のこの一連の変換は、開発者がタイムゾーンの詳細に完全に精通していない場合、簡単に特定できない可能性のある変換エラーの可能性を生み出します。
TimeZoneInfoとDateTimeOffsetを統合する新しいメソッドのセットまたは新しいクラスライブラリが作成され、開発者がdatetimeoffsetを新しいタイムゾーンに変換するように要求できるようになり、変換のチェーンに入る必要がないと思います。 これにより、エラーが減り、ほとんどの開発者にとってDateTimeOffsetの使用が簡単になります。
また、DateTimeOffset ToLocalは、Web上のアプリケーションのユーザータイムゾーンに変換するオプションを提供しないサーバーの日時/タイムゾーンを想定しています。クライアントはブラウザクライアントとは異なるタイムゾーンにある可能性があります。
また、ブラウザは、自分がいないタイムゾーンの日付を確認する必要がある場合があります。
あなたの提案を提供するために時間を割いていただきありがとうございます。 さらに先に進むことができることを確認するために、いくつかの予備チェックを行います。 問題が製品チームによってトリアージされたら、アップデートを提供します。
また、DateTimeOffset ToLocalは、Web上のアプリケーションのユーザータイムゾーンに変換するオプションを提供しないサーバーの日時/タイムゾーンを想定しています。クライアントはブラウザクライアントとは異なるタイムゾーンにある可能性があります。
また、ブラウザは、自分がいないタイムゾーンの日付を確認する必要がある場合があります。
この。 これがDateTimeKind
が壊れている理由です。 Utc
/ Local
/ Unknown
(または同様のAPIではOther
)は、ドメインの誤解を示しています。
java.timeやNodaTimeに似た、完全で最新の日付/時刻APIをファーストパーティで提供する必要があることを繰り返し述べます。
ほとんどの場合、 DateTimeOffset
も適切なドメインタイプではないことに注意してください。これは、非絶対インスタント情報は通常、 DateTimeZoned
として記録する方が適切であるためです(これにより、いつでも追加するとオフセットが自動的に更新されます)。
最も参考になるコメント
この。 これが
DateTimeKind
が壊れている理由です。Utc
/Local
/Unknown
(または同様のAPIではOther
)は、ドメインの誤解を示しています。java.timeやNodaTimeに似た、完全で最新の日付/時刻APIをファーストパーティで提供する必要があることを繰り返し述べます。
ほとんどの場合、
DateTimeOffset
も適切なドメインタイプではないことに注意してください。これは、非絶対インスタント情報は通常、DateTimeZoned
として記録する方が適切であるためです(これにより、いつでも追加するとオフセットが自動的に更新されます)。