ISO 8601 タイムスタンプ バリデータとフォーマッタ

このバリデータをチェックする

このバリデータは、実用的な開発者ワークフローのために設計されています。タイムスタンプや日付文字列を貼り付け、想定されるISO 8601の形状に一致するかを確認し、値がJSONに保存されたAPIに送信される前に明らかなフォーマットの問題をキャッチするか、設定ファイルにコピーします。 値が有効なISOスタイルの日付やタイムスタンプのように見えるか、ブラウザが不可能な日付ではなく実際の日付に解析できるかをチェックします。

このバリデータがチェックされていないもの

文字列は、ここで構造的に有効であり、アプリケーションにはまだ問題ありません。 このページでは、ビジネスルール、イベントの注文、APIスキーマの要件、またはタイムゾーンのオフセット、UTC Zのサフィックス、フラクショナル秒、または日付のみのフォーマットに関するダウンストリームサービスの主張がわからない。 フォーマットミスをキャッチするのに役立ちますが、最終的にタイムスタンプを消費するシステムによって定義された契約を置き換えません。

一般的な理由 ISO 8601 タイムスタンプ失敗

最も一般的な障害は簡単です:T区切り文字を欠落させ、厳密なタイムスタンプがTを期待するスペースを使用して、必要なタイムゾーンオフセットを省略し、追加の追跡テキストを追加したり、スプレッドシートまたはログビューアから隠し空白で値をコピーしたりします。 ISO 8601に近いように見えるので、タイムスタンプも失敗するかもしれませんが、ターゲットシステムが期待する正確な部分は含まれていません。

受諾された例および注入された例

良い例には、2026-03-05T17:46:39Z などのフル UTC タイムスタンプと、日付が必要とする 2026-03-05 などの日付のみの値が含まれます。 拒否された入力には、2026/03/05 のような値、スペースを持つタイムスタンプ、タイムゾーンなし、または部分的に欠落した時間フィールドを持つ文字列が含まれます。 問題が句読点、タイムゾーンの表記、または不可能なカレンダー値かどうかを確認する最速の方法です。

UTC、オフセット、Zの意味

ZサフィックスはUTCを意味します。 以下のような明示的なオフセットは UTC を表していますが、 -05:00 や +02:00 などの値は異なるローカルオフセットと同じ種類のタイムスタンプを表します。 2つの文字列は、UTCで書かれているので、画面上で異なるものを探している間、同じ瞬間を表すことができ、もう1つは地域のオフセットで書かれています。 つまり、タイムスタンプのデバッグには、パターンマッチングだけでなく、検証と解釈の両方が必要です。

Date-OnlyとDate-Timeの入力

2026-03-05 などの日付のみの値は ISO 8601 が有効ですが、時刻やタイムゾーンは持ちません。 期限、レポート範囲、およびカレンダーフィールドは、イベントタイムスタンプ、監査レコード、または正確なインスタントを必要とする API ペイロードでは許容できません。 この区別を使用して、値が単に有効であるか、または実際にテストしているシステムに適したかどうかを決定します。

無効なタイムスタンプを修正する方法

値をトリミングし、セパレータを確認します。 次に、対象システムが日付だけ、ZでUTCタイムスタンプ、または明示的な数値オフセットでタイムスタンプを期待しているかどうかを確認します。 スプレッドシート、ログエクスポート、またはコピーされたUIフィールドから値が来た場合は、追加のスペースを削除し、月、日、および時間ピースが完了していることを確認します。 小さな句読点の問題は、失敗した検証結果の実際の原因です。

プライバシーとローカルの検証

バリデーションはブラウザで実行されるため、ログ、Webhooks、スケジュール、および内部システムからのタイムスタンプをサードパーティのタイムスタンプチェッカーに送信することなく検査できます。 値自体が機密で、インシデントに縛られたり、代わりにローカルのデバッグセッションに保存するペイロードの一部である場合に便利です。