Unixタイムスタンプ：秒、ミリ秒、誤った日付
4つの入力、ひとつの瞬間。タイムスタンプが1970年や誤った日付になる理由を探ります。
1970年1月に該当するタイムスタンプは、単位が間違っていることがよくあります。1792069200という数字はUnix秒であり、1792069200000は同じ瞬間をミリ秒で表したものです。どちらも変換前にタイムゾーンオフセットを追加する必要はありません。
タイムゾーンコンバーターを開き、日付またはタイムスタンプを貼り付けを展開して、どちらかの数字を貼り付けて変換を選択します。フォームの下にある解釈を確認してください。両方とも2026-10-15T13:00:00.000Zになるはずです。
同じ瞬間を表す4つの方法
これらを1つずつ試すか、4つのタイムスタンプ例をダウンロードしてください：
1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00
最後の行はすでに翌日の深夜ですが、それでも同じ瞬間を表しています。明示的な11時間のオフセットがその差を説明しています。
このツールは、最初の数字を秒として、2番目の数字をミリ秒として読み取ります。今日の日付の場合、10桁と13桁の違いは有用な手がかりですが、タイムスタンプの普遍的な定義ではありません。このコンバーターは、推測する代わりに11桁および12桁の数値入力を拒否します。1900年から2100年までの日付をサポートしていますが、すべての歴史的なタイムスタンプ形式を解析するものではありません。
JavaScriptを書いている場合、数値のDateコンストラクターはミリ秒を期待します。MDNのDateリファレンスにその単位が記載されています。秒に1,000を掛けることは単位変換であり、タイムゾーンの調整ではありません。
時計だけでなく日付も確認する
タイムゾーンを追加を使用して、必要な都市を含めます。上記のサンプルの場合、テスト結果は次のとおりです：
| タイムゾーン | 現地の日時 | その日のUTCオフセット |
|---|---|---|
| UTC | 2026年10月15日 13:00 | +00:00 |
| Australia/Melbourne | 2026年10月16日 00:00 | +11:00 |
| Europe/London | 2026年10月15日 14:00 | +01:00 |
| America/New_York | 2026年10月15日 09:00 | -04:00 |
これらのオフセットはサンプルの日付に固有です。これらを都市間の恒久的な差として再利用しないでください。夏時間によって差が変わることがあります。定期的なタスクについては、cronと夏時間の例を参照してください。
時計カード内をドラッグすると共有された瞬間が移動し、すべてのカードが一緒に更新されます。すべての時間をコピーは、日付とオフセットもコピーします。これは、チームメイトに「9時」だけを送るよりも便利です。
オフセットのない日付は別の入力です
2026-10-15T13:00を貼り付け、タイムゾーンなしの場合は、次のように読み取られますをAustralia/Melbourneに設定します。2026-10-15T02:00:00.000Zになり、最初の例より11時間早くなります。
何も壊れていません。今回はローカルの時計の読み値を提供し、ソースのタイムゾーンが欠落しているコンテキストを補いました。Unix番号または明示的なオフセットの場合、そのソース選択は瞬間を移動しません。自分のタイムゾーンはデバイスのゾーンを追加できますが、デバイスはラベルのないログエントリが元々どのタイムゾーンを使用していたかを教えてくれません。
共有する前に曖昧な入力を解決する
このツールは、いくつかの入力を明確にするよう意図的に求めます：
10/11/2026 09:00は10月11日または11月10日を意味する可能性があります。年-月-日の日付を使用してください。2026-10-15 09:00 CSTは曖昧な略語を使用しています。完全なソースタイムゾーンを選択するか、明示的なUTCオフセットを指定してください。2026-11-01T01:30はAmerica/New_Yorkで時計が戻るときに2回発生します。意図したオフセットを指定してください。ローカルの時計の読み値だけでは選択できません。
2026年10月15日に、これらの入力と4つの同等のタイムスタンプをツールのパーサーに対して確認しました。変換出力と結果レコードは正確な値を保持しています。自然言語解析は言語によって異なります。時間を明確にする必要がある場合は、明示的な日付とオフセットがより良い選択です。