時間旅行におけるソフトウェアテスト - 現地時間の重要性

Question

ソフトウェアテスターとして、私はタイムトラベルのプラットフォームでのテストに関する事件に遭遇しました。 （時間は、テストの要件に応じて過去/未来に手動で設定することができます）

したがって、アプリケーション時間は現地時間と同じである必要はありません....または同じである必要がありますか？

現地時間とアプリ時間の不一致に起因するバグが見つかりました。簡単な説明：2つのバリデーションがあります。検証＃1はクライアント側のユーザー入力を検証し、検証のためにローカル日付を使用しています。検証＃2はサーバー側のユーザー入力を検証します（サーバー日付を使用しています）。両方のバリデーションは、プロジェクト仕様で指定されているビジネスルールに従います。 （ローカルで実行するか、サーバー側で実行するかは指定しません）これらの日付の間に矛盾があると、予期しない結果が発生します。

しかし、私のテストが間違っていて、その2つの日付を同期させるのはクライアントの責任であるというバグは、開発によって拒否されました。

正直、私の現地時間がアプリケーションの動作と関係している理由はわかりません。多くの機能とルールがあり、それらすべてのためにサーバー時間が参照ポイントとして使用されます。しかし、javascriptによって行われるクライアント側の検証のために、参照ポイントは現地時間です（デフォルトの動作であるため、意図的ではありません）。

あなたの意見を聞いています。それがバグだと思うのですか、それとも現地時間の重要性を理解していないのですか？あなたのプロジェクト（テスターまたは開発者として）でこのことをどうやって処理していますか？これは単にテストとサーバー時間の旅行の問題ではありませんが、クライアントの "時間の旅行"はどうでしょうか？ （例えば、異なる時間帯）。あなたはこのようなことに対処するためにあらゆる種類の楽器を置いていますか、それとも「悪い現地時間=顧客の問題」であり、それは開発の問題ではないと信じていますか？

Answer 1

一般に、実際にはアプリケーションに依存し、必要なこと、必要なものに依存します。しかし、ベストプラクティスとして、「適用時間」は常にUTCです。別のベストプラクティスとして、クライアントの時間を信用しないでください。エンドユーザーのコンピュータの時間が完全にずれているか、同期が外れているという大きな理由があります。

ほとんどすべてのアプリケーションで、アプリケーションサーバーをUTCに設定しました。エンドユーザにとっては、タイムゾーンのオフセットを決定するために使用するタイムゾーンを設定する必要があります。例えば、エンドユーザが「Eastern Timezone」を選択した場合、その設定を-5時間のオフセットとともに保存します（簡潔さのために夏時間を無視します）。データベースにユーザー設定を保存していない場合でも、クライアント側の設定画面でタイムゾーンを取得することも、JavaScriptを使用して自動的にタイムゾーンを取得することもできます。しかし、重要な要素は時間を無視し、タイムゾーン/オフセットを取得することです。その後、そのタイムゾーンをサーバーに送信し、サーバーの正確な時刻を使用して時刻を変換することができます。この方法では、正確なサーバー時間が得られますが、レポート、ロジック、または表示値のいずれかに使用できるユーザーの現地時間への参照になります。

あなたの質問に答えてください：ほとんどの場合、現地時間が悪いので、あなたの問題になるでしょう。エンドユーザーは、正確であることを確認するために時計をチェックするつもりはなく、IT担当者が問題を解決することなくアプリケーションを動作させることを期待しています。