クライアントがタイムゾーンを自己申告することに依存することの問題は、実際に取得するものがUTC オフセットである可能性が常にあることです (可能性の大きさについては議論の余地があります) 。UTC オフセットを取得すると、ロジックはほとんどの場合正常に機能しますが、実際には、クライアントによって生成された正確なタイムスタンプにのみ適用されます。過去または未来の時間は異なる UTC オフセットを持つ可能性があり、適切なタイム ゾーン データベースがないと予測できません。夏時間の境界近くで UTC オフセットを使用すると、壊滅的に間違った結果が生じる可能性があります。
それに加えて、識字能力のない一部のユーザー (おばあちゃんなど) は、ローカル システムのタイム ゾーンの設定方法を知らない場合があります。または、トンネル化されたセッションまたは仮想マシンのユーザーが、実際の設定に合わせて設定されていない「ローカル」タイム ゾーンを使用している可能性があります。
クライアントについて知っていること (IP など) に基づいてクライアントの政治的なタイム ゾーンを推測することは間違っている可能性があり、ユーザーが推測を無効にする方法がない場合は非常に煩わしい場合があります。しかし、匿名ユーザーまたは新規ユーザーのサインアップの場合、間違っている場合にユーザーに変更する方法を提供する限り、そのような方法を最初の推測として使用しても問題はないと思います。
私の推奨事項は具体的には次のとおりです。
- ユーザー プロファイルの一部として Olson タイム ゾーンを含めます。タイム ゾーンは国ごとに調べることができます。これにより、ユーザーはタイム ゾーンを比較的簡単に選択できるようになります。まっすぐな UTC の選択を気にかけている 0.01% のユーザーにも :-)
- IP ベースの推測でユーザー プロファイルの既定値を設定する場合、優れたルックアップ サービスを使用すれば、ほとんどの場合は正しくなります。ただし、間違っている場合はユーザーが変更できるようにします。
- 匿名ユーザーの場合は、現地時間を表示または入力するページにある種のウィジェットを提供して、ユーザー プロファイルの場合とほぼ同じ方法で Olson タイム ゾーンを選択できるようにします。選択した値を Cookie に保存します。デフォルトは UTC または上記の推測値です。
ローカライズされた時間でタイムスタンプを表示する必要がある以前の Web ベースのアプリケーションを実装する際に、すべてのクライアントが過去および将来の日付について UTC を現地時間に正しく変換するわけではないことがわかりました。サーバー側ですべての変換を実行する必要がありました。これには、現地時間と Olson タイム ゾーンを取得し、UTC 時間を返す Web サービスが必要になる場合があります。