メール時刻の意味

同じメールにも、4つの時刻がある

トリガー、キュー投入、受信、表示の時刻は同じではありません。まずタイムゾーンとイベントの定義をそろえ、認証コードが遅れたのか、期限切れなのかを判断しましょう。

10:00:00 トリガーユーザーがログインフォームを送信し、アプリが送信タスクを作成した時刻です。業務上の操作が発生した時点を示します。

10:00:02 キュー投入メールタスクが送信キューに入った時刻です。前の時刻との差から、アプリとキューの連携状況が分かります。

10:00:08 受信宛先サーバーがメールを受け付けた時刻です。キュー投入時刻との差は、実際の転送遅延に近い値です。

18:00:08 表示ブラウザーが UTC+8 のローカル時刻で表示しています。10:00:08 UTC と同じ瞬間である可能性があります。

まず意味を整理する

画面の時計だけで引き算しない

2台の端末で表示される時刻が違っても、必ずしも配信遅延を意味しません。各時刻を同じタイムゾーン、または同じタイムスタンプにそろえてから比較しましょう。

ユーザー操作やシステムイベントが発生した時刻です。製品が送信タスクをすぐに作成できたかを判断する材料になります。

通常は送信システムが記録しますが、サーバーの時計、キュー、設定の影響を受けることがあります。これだけで受信の証拠とみなしてはいけません。

受信システムが受け付けた時刻です。実際の到着状況を測るのに適していますが、どのタイムゾーンを使ったかを明確にする必要があります。

読みやすいように端末の形式へ変換されます。スクリーンショットを取る際は端末のタイムゾーンも記録しないと、チーム間で誤解が生じやすくなります。

認証コードのカウントは、生成時・送信時・サーバー発行時のいずれかから始まる場合があります。製品の仕様を基準にしてください。

カウントダウンは派生値です。バックグラウンド移行、スリープ、端末の時計変更後は、絶対的な有効期限から再計算してください。

遅延を診断する

どの区間で時間がかかったかが分かれば、アプリのログ、送信キュー、受信側のポリシーのどこを調べるべきか判断できます。

タスク作成が遅い

トリガーからキュー投入までの間隔が大きい場合は、アプリのリクエスト、テンプレートの描画、タスクサービスを優先して確認します。

キューの待機が長い

キュー投入から送信までの間隔が大きい場合は、レート制限、同時実行数、再試行、プロバイダーの状態を確認します。

転送・受信に時間がかかる

送信から受信までの間隔が大きい場合は、DNS、評価、メールの一時拒否、相手側のポリシーを確認します。

画面の更新が遅い

サーバーが受信済みなのに一覧への表示が遅い場合は、ポーリング頻度、キャッシュ、クライアントのネットワークを確認します。

まず有効期限がどのサーバーイベントを起点にするか確認し、有効期間内、境界の前後、再利用をそれぞれテストします。端末の時計を手動で変えて、サーバー側の期限切れを代用しないでください。

バグ報告には ISO 形式の元の時刻、タイムゾーンのオフセット、ローカルで読める時刻を併記します。スクリーンショットに「午前10時」とある場合は、端末のタイムゾーンも説明してください。

すばやく確認

次の4つの質問で、タイムゾーンに関する大半の誤解を解消し、本当の遅延がどのシステム工程で起きたかを調べられます。

アプリのログ、メールヘッダー、受信サーバー、ブラウザーの一覧のどれですか？出所によって示すイベントが異なります。

Z、明確なオフセット、地域のタイムゾーンが付いていますか？タイムゾーンのない時刻は、不完全な証拠として扱うしかありません。

件名の一意な番号、受信アドレス、タスク ID が一致している必要があります。再送メールを混ぜて比較しないようにしましょう。