日付文字列移植性チェッカー

日付・タイムスタンプ(またはログ全体)を貼り付け、JavaScript Date、Python、ほかの一般的なパーサーが異なって解釈・拒否する値と理由を確認します。

ブラウザー内でローカルに処理します。ファイルがアップロードされることはありません。

使い方 ツール

  1. 日付文字列1つ、または日付を含む文章を貼り付けます。内容はブラウザー外へ送信されません。
  2. 「日付を確認」を選びます。
  3. 指摘ごとに曖昧さや危険性、実行環境間の差を確認します。
  4. 安全な変換案がある場合はISO 8601表記を使います。自動解決できない曖昧さは推測せず説明します。

前提条件

出典と参考データ

方法論

日付らしい部分文字列を形式で分類し、JavaScript Date、Python、厳格なパーサー(一部SQLエンジンを含む)の既知の差を確認します:時刻のない日付の暗黙UTC/ローカル午前0時、オフセットなし日時のローカル/UTC解釈、2桁年の世紀推定、ゼロ埋めなし要素の拒否。曖昧さのないISO 8601変換だけを提案し、推測はしません。

計算例

スラッシュ区切りの曖昧な日付

入力項目: 01/02/2024

結果: 1も2も月になり得るため、規則により1月2日または2月1日です。誤りとして指摘し、順序を推測する方が問題の可視化より危険なため自動変換しません。

日付だけのISO文字列

入力項目: 2024-01-15

結果: JavaScriptの`new Date("2024-01-15")`はUTC午前0時としますが、ほかの言語とJavaScriptの`new Date(year, month, day)`形式ではローカル午前0時です。UTCより西のタイムゾーンでは暦日が異なる場合があります。リスクを警告しますが、有効なISO 8601なので変換しません。

ゼロ埋めされていない日付

入力項目: 2024-1-5

結果: JavaScriptとPythonは寛容に受け付けますが、一部の厳格なSQL日付パーサーは拒否します。安全な形式`2024-01-05`へ変換します。

実用的なアドバイス
よくある間違い

よくある質問

なぜ01/02/2024はエラーで、25/12/2024は情報扱いですか?

前者では1と2のどちらも月として有効で、文字列だけから順序を決められません。後者では25は月になれず日/月順と分かります。ISO 8601ではありませんが曖昧でなく、重大度が低く自動変換できます。

2桁年の「24」を2024と仮定しないのはなぜ?

可能性は高いものの、世紀推定規則によって同じ文字列を1924または2024とするシステムがあります。誤った推測が無推測より悪い場合、代わりに推定しません。

2024-01-15のような日付のみの文字列は本当に危険ですか?

JavaScript Dateと多くのパーサーで表す瞬間が異なる点に限ってリスクがあります。JavaScriptはUTC、多くの言語はローカル時刻とします。テキストや保存値としては安全で、日付オブジェクトへ解析し瞬間を問うと差が現れます。

`new Date('2024-01-15')`が前日を示すことがあるのはなぜ?

ECMAScriptは日付のみのISO形式をUTC午前0時と解釈します。UTCより西の地域でローカル表示すると前暦日になることがあります。ローカル午前0時を作る場合やタイムゾーンのない日付として扱う場合とは異なります。このチェッカーは形式に基づくリスクを説明し、他言語のパーサーを実行しません。

最終確認日: 2026-09-25

完全な日付パーサーではなく、5種類の形式を認識する限定的なスキャナーです。自然言語日付、Unixタイムスタンプ、特殊な地域形式は解析しません。本当に曖昧な値の意図も判断せず、その曖昧さを報告します。

テーマとツールの設定、保存済みリストと最近使用したリストは、このブラウザー内にのみ保存されます。