開発者ツール · Unix タイムスタンプ コンバータ
1000 によるバグ: 日付に 1 月 1970 または年 56000 が表示される場合
· なぜそれが重要なのか
タイムスタンプ デバッグ 開発者ワークフロー
ミリ秒が期待されるところで秒が過ぎてしまう (またはその逆) ことは、最も一般的なタイムスタンプのバグです。この投稿では、各方向でどのように見えるか、言語間のどこに隠れているか、そして数秒で捕まえる方法を示します。
すべてのユーザーは 1 1 月 1970 に参加しました — バグを解消する画面と、完全に正しいバックエンド
1 月付近のすべてのアカウントを表示するプロフィール ページ 1970 は、強力なスケールの症状です。フロントエンド コードがミリ秒を解釈する Date コンストラクターに直接エポック秒を渡している間、バックエンドは正しいエポック秒を返している可能性があります。現在のカウントは、カレンダー軸上で 1,000 分の 1 に縮小されます。
定数年を追加したり日付を置き換えたりして表示をパッチしないでください。生のフィールド、その API コントラクト、および正確なコンストラクター呼び出しをキャプチャします。 ToolAcre を使用すると、両方のユニットを強制できるため、運用データを変更せずに 1 つの値をテストできます。別の既知のイベントと一致する読み取り値により、可能性のある境界エラーが特定されます。
2 つの症状 — 1970 1 月に着陸したミリ秒 API に供給された秒数と、数万年後に着陸した秒 API に供給されたミリ秒数
10 億ミリ秒は 1 世紀のほんの一部にすぎないため、ミリ秒として解釈される秒はエポックに近くなります。逆の間違いにより、1 兆ミリ秒の値が 1 兆秒に拡張され、多くの場合、通常のアプリケーションの範囲を超えます。どちらの失敗もスケールを変更しながら桁を保持します。
公開された 10 桁対 13 桁の記事では、現代の視覚ヒューリスティックとその限界についてすでに説明しています。この記事では、代わりに、診断と予防、つまり明示的なユニットの選択、独立したイベントの証拠、および生産者の表現が消費者の契約を満たすインターフェースでの 1 つの変換に焦点を当てます。
両方の分岐が決定的であるため、症状は 1 つのフィクスチャで再現できます。これにより、断続的なクロック ドリフトやロケール フォーマット動作よりも、単位の不一致の証明が容易になります。
境界は通常、JavaScript と Java はミリ秒、Unix ツール、Python およびほとんどのデータベースは秒、そしてそれらの間の JSON ペイロードです。
このリポジトリは、JavaScript Date がミリ秒を消費し、ToolAcre が構築する前に秒を乗算することを証明します。ワークブック内で指定されているすべての Java、Python、シェル、またはデータベース API のデフォルトを確立するわけではありません。これらの契約は、使用される場所を確認する必要があります。
JSON 番号にはユニット メタデータは含まれません。フィールドに `created_at` という名前を付けると、サービス間で曖昧さがなくなります。 `created_at_s` という名前を付けるか、ISO 文字列を文書化すると、契約がレビュー可能になります。受信アダプターは、ビュー間で乗算を分散させるのではなく、内部表現に一度変換する必要があります。
再利用可能な表示ヘルパー内ではなく、境界定義の横に変換を記述します。アダプターはプロデューサー コントラクトを知っています。汎用フォーマッタは、すでに正規化されたインスタントを受け取る必要があります。
ユニット境界は API 固有です。このリポジトリは、JavaScript の日付がミリ秒を使用していることを証明しています
`0` などの弱いフィクスチャでは、0 秒と 0 ミリ秒の両方がエポックに名前を付けるため、バグを検出できません。小さな捏造された値は、もっともらしい 1970 日付のように見えることもあります。消費者が期待するのと同じスケールを返すモックは、実際の統合不一致を引き起こすことはありません。
ゼロ以外の既知の瞬間を選択し、2 つの解釈を明らかに異なるものにします。 Date オブジェクトが存在するというだけでなく、境界における正規の ISO 結果をアサートします。ミリ秒の場合と秒の場合を含めます。 ToolAcre 独自のテストでは、まさにこの理由から各ユニットの 1,000,000 を比較します。
テストで 2 つのスケールを区別できない場合でも、ユニットのバグは存続します。
`created_at: 1738578000` を検討してください。秒単位で強制すると、`2025-02-03T10:20:00.000Z` になります。ミリ秒として強制すると、`1970-01-21T02:56:18.000Z` になります。 2 月に作成されたことが知られている展開レコード 2025 は、桁数だけに依存せずに曖昧さを解決します。
アダプターを修正する間は、生の JSON を既知のイベントの横に保持してください。フィールドが `1738578000000` の場合、ミリ秒解釈により同じ瞬間が識別されます。コンバーターが正しいスケールを適用した後でそれらの等価性を実証できる場合でも、2 つの値は 1 つのスキーマ内で交換可能に受け入れられるべきではありません。
既知の展開日は独立した証拠です。それがなければ、よりもっともらしい出力を選択すると、制作者が意図したものを確立するのではなく、研究者の期待を暗号化してしまう可能性があります。
実用的な例: 両方の明示的な単位で created_at 値をテストする
永続的な修復は境界から始まります。文書化されたソースユニットを解析し、正確に 1 回変換して、型指定された、または明確に名前が付けられた内部値を公開します。スキーマの説明、例、および生成されたクライアントは、サフィックスまたは日付/時刻形式を保持する必要があります。レビュー担当者は、実行前に余分な乗算を見つけることができます。
実際のスケールと固定 ISO 期待値を使用した回帰フィクスチャを追加します。プロデューサーが契約を結んでいる場合は、アプリケーション コードでの自動検出を避けます。ヒューリスティックは、不確実なレガシーデータを調査するためのものです。 ToolAcre は、検出された選択肢に正確にラベルを付けるため、推測が保証されたメタデータになりすますことができません。
これでカバーされないもの — 日付を数十年ではなく時間単位でずらすタイムゾーンの間違い
タイムゾーンエラーは通常、表示を時間単位でシフトし、1 暦日をまたぐ場合があります。 1,000 の係数の誤差は、数十年または数千年単位で変化します。診断を混合すると、すでにスケールが間違っている値を中心としたオフセット調整が促進されます。ローカルのフォーマットを検査する前に、ユニットを確認してください。
同様に、間違ったエポック起点は、秒とミリ秒の両方で無意味なままになる可能性があります。どちらの解釈も既知のイベントと一致しない場合は、切り替えを停止してプロデューサーを調査します。コンバーターは仮説を絞り込みます。すべての大きな整数が Unix 時間であることを証明するものではありません。
年は妥当であるが、時間が一貫してずれている場合は、ゾーンの表示を調査してください。これらの症状スケールを分離しておくと、スクリーンショットから根本原因に至るまでのパスが短くなります。
要点: 間違った単位は間違った世紀です — そして、Unix タイムスタンプ コンバーターの指定された単位を使用して両方の読み取り値を瞬時にテストできる方法
間違った単位は表面的なメタデータではなく、瞬間を変えます。 1970 の重い画面と信じられないほど遠い年月を、生産者と消費者の継ぎ目を検査する信号として扱います。価値、単位契約、および既知のイベントは、明らかに妥当な日付よりも強力な 3 つの部分からなる証明を形成します。
コンバーターを使用して明示的な読み取り値を比較し、選択したスケールを名前、タイプ、およびテストでエンコードします。目的は、より賢く推測できるようにソフトウェアを教えることではありません。これは、ユーザーの日付を作成するパスから推測を削除するためです。
コード レビューでは、各境界で 1 つの正確な質問をすることができます。つまり、どのユニットが入り、どのユニットが離れるのかということです。これは、特定の桁数を認識するよりも信頼性が高くなります。