REST APIは、日時を適切なクライアントのタイムゾーンに変換できますか？
APIの実装中に、日時とタイムゾーンの問題が発生しました。
すべての日付はデータベースのUTCに正規化されます。現在、非APIアプリケーションでは、すべての日時は、表示される前にまずユーザーの設定に基づいて変換されます。
APIについても同じ質問が出されました。APIは、リクエストのセマンティクスに基づいて、タイムゾーンに適した日時を返すことができますか？
例えば。 GET /posts?timezone=America/Sao_Paulo？
それとも、APIにアクセスしているクライアントで実行する必要がありますか？
pdate：数回使用されたため、現在タイムスタンプwithタイムゾーンが返されます（ただし、常にTZオフセットです+00:00）。形式は人気のある8601です：2015-10-29T23:00:49+00:00
absoluteの時点を返す必要があります。そうすると、誰でも必要に応じてそのタイムスタンプをローカライズできます。 「絶対タイムスタンプ」とは、UNIXタイムスタンプか、標準化されたISO形式のいずれかでタイムゾーンを含む人間が読めるタイムスタンプのいずれかを意味します。 「2007-04-05T14：30Z」。これは、クライアントが必要に応じて、簡単にローカルタイムゾーンに変換できます。
タイムゾーンパラメータを受け入れ、タイムスタンプをそのタイムゾーンにローカライズしたいが、それでも絶対タイムスタンプを使用する必要がある場合。応答のタイムゾーン（例： 「2007-04-05T16：30-02：00」。この値が以前のローカライズされていない値と同じであることを考えると、このパラメーターを提供するという問題を経験する理由にはかなり疑問があります。タイムスタンプの正確な表示形式は、最終的にはクライアントのフロントエンド次第なので、とにかく値を後処理する可能性があります。
日時値をユーザーのローカルタイムゾーンに変換するロジックがすでにある場合は、APIで両方の可能性を提供できます。
クライアントがGET /posts、その後、デフォルトのタイムゾーン（UTC）ですべての時間を取得します。
クライアントがGET /posts?timezone=America/Sao_Paulの場合、応答のすべての時間が指定されたタイムゾーンに調整されます。
タイムゾーンで何をしたいかはクライアントの実装次第です。
通常、APIからUTCを期待します。
ただし、「REST API」がJavaScriptフレームワークを使用するWebページのサーバー側の一部である場合。実際にはViewModelを返すので、ローカライズされた文字列、数値、時間を含める必要があると私は主張します。
それは悪い、悪い、悪い考えです。クライアントがサーバーからの応答を保存し、ユーザーが別のタイムゾーンに移動する状況を考えます。これで、この「機能」がせいぜい何の利点も与えないか、大きなトラブルを引き起こす状況になっています。
ところで。これをテストする予定のタイムゾーンとクライアントの数は？サーバーがAmerica/Sao_Paulに対して予期される応答を返した場合、America/Sao_Pauloに対して何が応答されますか？