バックエンドまたはフロントエンドでのタイムゾーン変換
ASP.NET APIバックエンドとReactフロントエンドを備えたWebアプリがあります。また、React Nativeに組み込まれたモバイルアプリもあります。
質問は日付/時刻の値についてです。タイムゾーン変換の処理には2つのオプションがあり、どちらがより良いアプローチであるかについていくつかの意見を得たいと思っています。
- ユーザーのタイムゾーンをデータベースに保存し、保存されたタイムゾーンデータに基づいて、既にユーザーのタイムゾーンに変換されたすべての日付/時刻値を送信できます。このアプローチの利点は、フロントエンドが何もする必要がないことです。これは、システムリソースが限られている古いスマートフォンの場合に特に有利です。
- 2番目のオプションは、UTC値をReactフロントエンドおよびモバイルアプリに送信し、JavaScriptに実行時にキャプチャするユーザーのタイムゾーンに基づいて日付/時刻値を表示する作業を処理させることです。 。このアプローチの利点は、JavaScriptがユーザーのタイムゾーンをリアルタイムでキャプチャし、より正確にすることができることです。たとえば、ユーザーは彼/彼女が米国東部時間帯にいると私に言った後、カリフォルニア、つまり米国太平洋時間帯に旅行するかもしれませんJavaScriptにタイムゾーンデータを処理させることで、ユーザーが別のタイムゾーンに移動することによって生じる心配を解消できると思います。
一般的なルールは、「常に日時をUTCとして送信する」であり、プレゼンテーションレイヤーでのみ変換されます。
ただし、javascriptは日時が指定されていません。したがって、必要な変換サーバー側を実行し、両方を送信します。
時間でアイテムを注文したり、夏時間などを気にせずに「1時間追加」のようなデータの操作をしたりする場合は、UTCが必要です。
実際、おそらくUTC、現地時間、ユーザーの現地時間、およびそれらのローカライズされた文字列バージョンを送信する必要があります。クライアント側のものをプレゼンテーション層として扱う
これは、ASP/Reactの問題だけでなく、サーバー/クライアントの相互作用に関する一般的な問題にも当てはまると思います。
次の質問に答えてみてください。
タイムゾーンは実際にクライアントにとってどれほど重要ですか？時間が重要な配信サービスですか、それとも時間が使い捨ての写真編集サイトですか？
上記の結果として、クライアントのタイムゾーンを自動検出しても安全ですか、またはタイムゾーンが非常に重要なので、常にユーザーが明示的なオプションを設定する必要がありますか？
タイムゾーンは非常に重要なので、クライアントが複数のゾーンで時間を表示する必要があるかもしれませんか？例えばサーバーにクライアントのデフォルトのタイムゾーンを保存させる。クライアントがタイムゾーンの移動を検出したと報告した場合は、ローカルゾーンとデフォルトゾーンの両方で時刻を表示するようにユーザーに提案します。
クライアントはどのくらいの頻度で動き回ると予想されますか？クライアントは輸送トラックにいますか、それともデータウェアハウスのサーバーですか？
これらの質問に対する答えは、コスト（開発時間、保守性、複雑さ）とメリットの比較に役立つと思います。
時間とタイムゾーンの経験から、同じことが行われるさまざまな場所の数を最小限にしたいことがわかりました。
「今」の単一のソース。クライアントの現在の時刻が必要な場合は、サーバーに問い合わせてください。これにより、「数分ずれた」エラーのクラス全体が取り除かれます。
タイムゾーンルールの単一のソース。サーバーでタイムゾーン変換を一貫して同じTZデータベースから行うことをお勧めします。これにより、システムの一部でTZデータベースが更新され、他の部分では更新されないため、奇妙な違いはありません。
時間を表す単一の方法。 ISOタイムスタンプは、オフセットと日付と時刻の両方が読みやすい方法で含まれているため、私が好みます。
考慮すべき重要な点は、date + time + offsetがどのタイムゾーンに関係しているかを通知しないことです。タイムゾーンは、UTC時間に適用すると現地時間を与えるが、他の方向には使用できない計算規則です（DSTやその他の奇妙さのために、一部の現地時間は2回発生するかまったく発生しないため）。したがって、タイムゾーン変換を行うには、（A）UTCでの日付と時刻（またはdatetime + offsetなどのUTCに変換可能なもの）、および（B）タイムゾーン識別子が必要です。どちらもクライアントに出荷できますが、APIが見苦しくなります。