REST APIは、日時を適切なクライアントのタイムゾーンに変換できる必要がありますか？

APIの実装中に、日時とタイムゾーンの問題が発生しました。

データベースでは、すべての日付がUTCに正規化されています。現在、非APIアプリケーションでは、すべての日時は、表示される前にまずユーザーの設定に基づいて変換されます。

APIについても同じ質問が浮上しました。APIは、要求のセマンティクスに基づいて、タイムゾーンに適した日時を返すことができる必要がありますか？

例えばGET /posts?timezone=America/Sao_Paulo？

それとも、APIにアクセスしているクライアントで実行する必要がありますか？

更新：数回発生したため：現在、タイムゾーン付きのタイムスタンプが返されます（ただし、常にTZオフセットです+00:00）。形式は人気のある8601です。2015-10-29T23:00:49+00:00

絶対的な時点を返す必要があります。そうすれば、誰でも必要に応じてそのタイムスタンプをローカライズできます。「絶対タイムスタンプ」とは、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に対して何が応答されますか？