Runtime: TimeZonesとDateTimeOffset

作成日 2019年11月27日  ·  1コメント  ·  ソース: dotnet/runtime

_この問題は、開発者コミュニティのチケットから移動されまし


現在、DateTimeOffsetにはタイムゾーン変換のオプションがなく、TimeZoneInfoのWindowsAPIはDateTimeOffsetをサポートしていません。

これにより、日時オフセットを日時に変換するコードを記述し、TimeZoneInfoを使用して新しい日時に変換してからDateTimeOffsetに戻す必要があります。これにより、目的の時点とタイムゾーンが維持されます。

フォーマットと関連するAPI呼び出しの間のこの一連の変換は、開発者がタイムゾーンの詳細に完全に精通していない場合、簡単に特定できない可能性のある変換エラーの可能性を生み出します。

TimeZoneInfoとDateTimeOffsetを統合する新しいメソッドのセットまたは新しいクラスライブラリが作成され、開発者がdatetimeoffsetを新しいタイムゾーンに変換するように要求できるようになり、変換のチェーンに入る必要がないと思います。 これにより、エラーが減り、ほとんどの開発者にとってDateTimeOffsetの使用が簡単になります。


元のコメント

2019年3月15日午前8時16分にデニーフィゲレス:

また、DateTimeOffset ToLocalは、Web上のアプリケーションのユーザータイムゾーンに変換するオプションを提供しないサーバーの日時/タイムゾーンを想定しています。クライアントはブラウザクライアントとは異なるタイムゾーンにある可能性があります。

また、ブラウザは、自分がいないタイムゾーンの日付を確認する必要がある場合があります。

Jane Wu [MSFT]、2019年3月18日午前1時36分:

あなたの提案を提供するために時間を割いていただきありがとうございます。 さらに先に進むことができることを確認するために、いくつかの予備チェックを行います。 問題が製品チームによってトリアージされたら、アップデートを提供します。

api-needs-work api-suggestion area-System.Runtime

最も参考になるコメント

また、DateTimeOffset ToLocalは、Web上のアプリケーションのユーザータイムゾーンに変換するオプションを提供しないサーバーの日時/タイムゾーンを想定しています。クライアントはブラウザクライアントとは異なるタイムゾーンにある可能性があります。

また、ブラウザは、自分がいないタイムゾーンの日付を確認する必要がある場合があります。

この。 これがDateTimeKindが壊れている理由です。 Utc / Local / Unknown (または同様のAPIではOther )は、ドメインの誤解を示しています。

java.timeやNodaTimeに似た、完全で最新の日付/時刻APIをファーストパーティで提供する必要があることを繰り返し述べます。
ほとんどの場合、 DateTimeOffsetも適切なドメインタイプではないことに注意してください。これは、非絶対インスタント情報は通常、 DateTimeZonedとして記録する方が適切であるためです(これにより、いつでも追加するとオフセットが自動的に更新されます)。

>すべてのコメント

また、DateTimeOffset ToLocalは、Web上のアプリケーションのユーザータイムゾーンに変換するオプションを提供しないサーバーの日時/タイムゾーンを想定しています。クライアントはブラウザクライアントとは異なるタイムゾーンにある可能性があります。

また、ブラウザは、自分がいないタイムゾーンの日付を確認する必要がある場合があります。

この。 これがDateTimeKindが壊れている理由です。 Utc / Local / Unknown (または同様のAPIではOther )は、ドメインの誤解を示しています。

java.timeやNodaTimeに似た、完全で最新の日付/時刻APIをファーストパーティで提供する必要があることを繰り返し述べます。
ほとんどの場合、 DateTimeOffsetも適切なドメインタイプではないことに注意してください。これは、非絶対インスタント情報は通常、 DateTimeZonedとして記録する方が適切であるためです(これにより、いつでも追加するとオフセットが自動的に更新されます)。

このページは役に立ちましたか?
0 / 5 - 0 評価