Unixタイムスタンプ・ジェネレーター

仕組み

1. 日付をタイムスタンプに変換: ピッカーで日付と時刻を入力し、生成をクリックして秒とミリ秒のUnixタイムスタンプを取得します。
2. タイムスタンプを日付に変換: Unixタイムスタンプ(秒またはミリ秒)を貼り付けて、読みやすい日付と時刻に再変換します。
3. 現在のタイムスタンプを取得: 「今」をクリックして、現時点のUnixタイムスタンプを瞬時に取得します。

なぜUnixタイムスタンプジェネレーターを使うのか?

Unixタイムスタンプは、コンピューティングにおける時間の普遍的な言語です, 1970年1月1日(UTC)からの経過秒数を表す単一の整数。これらは、データベース、API、ログ、認証トークン、イベントスケジューリングを動かしています。タイムスタンプと読みやすい日付を手動で変換するには、ミスしやすいタイムゾーンの計算が含まれます。このツールは双方向の変換を正しく処理し、時間を節約してタイムゾーンのバグを回避します。

機能

• 双方向変換: 日付/時刻 → Unixタイムスタンプ、Unixタイムスタンプ → 日付/時刻。
• 秒とミリ秒: 秒(10桁)とミリ秒(13桁)の両方のUnix時間をサポート。
• タイムゾーン処理: 明確な比較のために、ローカルタイムゾーンとUTCで時刻を表示します。
• 現在時刻ボタン: 現時点のタイムスタンプを瞬時に取得します。
• 相対表示: どのくらい前またはどのくらい後を示します(例: 「3日前」)。

よくある質問

Unixタイムスタンプとは?

Unixタイムスタンプは、Unixエポック, 1970年1月1日UTCの真夜中, からの経過秒数です。これはタイムゾーンに依存しない瞬間の表現であり、データベースとAPIで瞬間を保存および比較するための好ましい形式です。

なぜJavaScriptはミリ秒を使用しますか?

JavaScriptのDate.now()とnew Date().getTime()はエポックからのミリ秒(13桁の数字)を返しますが、Unixツールとほとんどのデータベースは秒(10桁)を使用します。タイムスタンプが10桁か13桁かを確認して、どの形式があるかを判断してください。

タイムスタンプをローカル時間に変換するには?

タイムスタンプを貼り付けます。ツールは自動的にブラウザのローカルタイムゾーンに変換します。表示には、タイムゾーンを越えて自信を持って作業するために、ローカル時間とUTCの両方が表示されます。

Unix時間の起源

Unix時間は、Ken ThompsonとDennis RitchieによってUnix First Edition(1971年11月)で定義されました。当初、カーネルは1971-01-01からの60分の1秒を32ビットフィールドでカウントしており、2年9ヶ月後にオーバーフローしました。Unix Sixth Edition(1975)までに、カウントは1970-01-01 00:00:00 UTCからの秒数に変更され、これは現在もUnix系すべてのシステムが使用しているエポックです。選択は恣意的でした、エンジニアは作業していた時代に近い丸めた日付が必要だったのです。POSIX.1(1988)はこの定義を公式標準として成文化し、POSIX.1-2017(IEEE Std 1003.1-2017)、現行版は依然としてtime_tをエポックからの秒数として定義しています、POSIX時間はうるう秒が存在しないふりをするという但し書きとともに。ISO 8601(1988、現在は2019)は読みやすい形式2026-05-13T14:30:00Zを標準化し、RFC 3339(2002年7月)はそれを明確なインターネット日時プロファイルに絞り込みました。JavaScriptのDate.now()はエポックからのミリ秒を返します、これは仕様が1995年に書かれた時点ですでにサブ秒精度が需要されていたからです;ほとんどのデータベースとUnixユーティリティは依然として整数秒を使用します。

2038年問題(そしてそれが今重要な理由)

符号付き32ビットtime_tは最大2,147,483,647秒を表現でき、これは2038年1月19日火曜日UTC 03:14:07に到達します。1秒後、カウンタは−2,147,483,648にラップし、ほとんどのソフトウェアはこれを1901年12月13日として解釈します。これはY2Kと同じクラスのバグですが、日付形式ではなく整数幅によるものです。修正は64ビットtime_tを使うことです(これによりラップアラウンドが約292十億年へ押し戻されます)。ほとんどの64ビットLinuxシステムはすでにデフォルトで64ビットtime_tを使用しています;Linux 5.6(2020年3月)は32ビットアーキテクチャでも64ビットtime_tを利用可能にしました。残るリスクは組み込みシステム、古いバイナリファイル形式、32ビットネットワークプロトコルにあります。ネットワークタイムプロトコル(NTP)は1900年からの符号なし32ビットカウントを使うため、すでに2036年にラップします、NTPv4は時代番号を追加してそれを拡張します。日付を扱うソフトウェアを出荷する場合、2038年より前にスタックを監査してください、特にINT(11)として型指定されたSQLカラムやlong時間フィールドを持つ古いCコードを。

出会うタイムスタンプ形式

• Unix秒(10桁)。 1747143000。古典的なPOSIX time_t。PostgreSQL EXTRACT(epoch FROM ...)、MySQL UNIX_TIMESTAMP()、Redis TTL、JWT iat/expクレーム(RFC 7519に従う)、git log、およびほとんどのUnixユーティリティで使用。2286年11月以降は11桁になります。
• Unixミリ秒(13桁)。 1747143000000。JavaScriptのDate.now()、JavaのSystem.currentTimeMillis()、Kafka、Elasticsearch、およびほとんどの最新のロギングパイプライン。秒カウントの1000倍。
• Unixマイクロ秒(16桁)とナノ秒(19桁)。 1747143000000000。Pythonのtime.time_ns()、Goのtime.Now().UnixNano()、etcd MVCCリビジョン、およびミリ秒解像度では粗すぎる高頻度取引システムで使用。
• ISO 8601。 2026-05-13T14:30:00.000Zまたは2026-05-13T14:30:00+02:00。文字列としてソート可能、タイムゾーンについて明確、事実上すべての現代APIで受け入れられる。Zサフィックスは「Zulu時間」を意味し、UTCのNATO指定子。
• RFC 3339。 JSON Schema、OpenAPI、およびほとんどのREST APIで使用されるISO 8601のより厳格なプロファイル。タイムゾーン指定子が必要で、週次日付や順序日付などの一部のISO 8601機能を禁止。
• RFC 2822 / RFC 5322。 Tue, 13 May 2026 14:30:00 +0000。電子メールDate:ヘッダー形式。SMTPがどこでも実行されているため依然として遍在。
• Excelシリアル日付。 1900-01-01(またはクラシックMac Excelでは1904年)からの分数日。2026-05-13 14:30は約46150.6042。ExcelはLotus 1-2-3互換性のため、1900年をうるう年(そうではない)として扱うことで有名。

このツールが価値を発揮するとき

• JWTデバッグ。 トークンに"exp": 1747143000があり、期限切れかどうか知る必要がある。貼り付け、人間の日付を見る。
• ログフォレンジック。 一行がtimestamp=1747143012345と言い、別のツールの壁時計時刻と相関させる必要がある。13桁、つまりミリ秒。
• データベースクエリ。 特定の日付以降の行を見つけたい。WHERE created_at > 1747143000には秒値が必要;ツールからコピー。
• テストフィクスチャ。 テストで「昨日」をハードコーディング、今タイムスタンプを生成してスペックに貼り付ける。
• Cron / スケジュールされたジョブ。 スケジューラーが発火する秒値を、特にDST遷移を通じて確認。
• イベントリプレイ。 KafkaオフセットとElasticsearchインデックスはしばしばmsタイムスタンプを使用;特定のリプレイウィンドウを検査するために日付に変換。
• キャッシュ無効化。 RFC 2822形式のExpiresヘッダーまたはIf-Modified-Since、テスト用に正しいワイヤー形式を生成。

チームに時間を費やさせるミス

• 秒とミリ秒を混同。 ミリ秒を期待する関数に10桁の値を渡すと1970年の日付が返り、1000倍ずれる。10対13桁ルールが最速のテスト、秒の現代の値は2286年まで10桁、ミリ秒は13桁。
• ローカル時間を保存。 常にUTCを保存;表示時にローカルに変換。タイムゾーンなしの"2026-05-13 14:30:00"保存は、サーバー、ユーザー、またはDSTジャンプがローカルオフセットを変更する瞬間に壊れる。
• DST遷移を忘れる。 午前2:30は秋戻り中に2回発生。「明日」を意味するためにstart + (24 * 3600)を行う素朴なコードは年に2回1時間ずれる。IANA tzデータベースを知っている実際の日付ライブラリ(luxon、date-fns-tz、Pythonのzoneinfo)を使用。
• POSIX時間がうるう秒を考慮すると仮定。 考慮しません。2016-12-31 23:59:60は実生活で存在しました(27番目のうるう秒)がPOSIX time_tは追加の秒の認識なしに23:59:59から00:00:00にジャンプ。TAI(国際原子時)はうるう秒をカウントし、POSIX時間はUTCから0秒オフセット。
• time_tをINT(4)カラムに保存。 古いMySQLスキーマは頻繁にINTを使用、これは4バイト/符号付き32ビット/2038年にラップ。BIGINTまたはTIMESTAMPに移行。ホスト型MySQLプロバイダーのTIMESTAMP型もデフォルトで4バイト、ドキュメントを確認。
• 正規表現でISO 8601をパース。 半端な実装は静かにタイムゾーンを落とす。プラットフォームパーサーを使用:JavaScriptでnew Date(s)、Python ≥ 3.11でdatetime.fromisoformat(s)、JavaでInstant.parse(s)。
• Excelは自動的にタイムスタンプを変換。 '(リテラルアポストロフィ)で接頭辞をつけずに1747143012345をExcelに貼り付けると、Excelはそれを数値として読み、時には科学的記法に変換。最初にカラムをテキストとしてフォーマットするか、アポストロフィ接頭辞付きで貼り付け。

その他のよくある質問

なぜ1970-01-01がエポックとして選ばれたのか?

便利だから。1970年代の初期のUnixバージョンは、合理的な作業寿命内にオーバーフローしないエポックを望んだ。1970-01-01は開発時代に近い丸めた日付で、そこから32ビット秒カウンタは2038年まで快適に到達する。この選択は今やPOSIX.1-2017 §4.16に刻まれており、ソフトウェアで最も安定したクロスプラットフォーム合意の1つ。日付に固有の意味はなく、歴史的イベントもなく、天文学的アンカーもなく、ただ全員が合意した恣意的なアンカー。

UTC、GMT、Zulu時間の違いは?

ソフトウェア目的では、同じ壁時計時刻を指す。UTC(協定世界時)は現代の標準、原子時計とBIPMで定義。GMT(グリニッジ平均時)はより古い英国天文標準、原子時刻管理前は事実上の世界基準。Zulu時間はUTCのNATO/軍事指定子、ISO 8601でZサフィックスとして書かれる(2026-05-13T14:30:00Z)。UTCとGMTは最大0.9秒異なる可能性がある、UTCはうるう秒を介してUT1(平均太陽時)に近く保たれるが、UT1を直接使用しないアプリケーションは気づかない。

期待した別のものではなく時々1970が表示されるのはなぜ?

2つの一般的な原因。第一に、タイムスタンプがミリ秒なのに秒を期待する関数に渡された、またはその逆、1000倍ずれた日付を与える。第二に、値が0またはNaN、ほとんどの日付ライブラリは両方とも1970-01-01T00:00:00Zとしてレンダリング。生の整数幅を検査:10桁は秒、13はミリ秒、16はマイクロ秒、19はナノ秒。

このツールは1970年より前の日付の負のタイムスタンプを処理しますか?

はい。new Date(-86400000)は1969-12-31T00:00:00Zを返す。JavaScriptのDateは−271821-04-20から+275760-09-13までの任意の瞬間を表現でき、これはエポックから約±1億日。その範囲を超えると、APIはInvalid Dateを返す。歴史的な日付については、ユリウス・グレゴリオ移行(カトリック諸国は1582年、英国は1752年、ギリシャは1923年と遅く)も認識、ここでカレンダーの日付は10から13日ジャンプした;日付ライブラリはこれを扱う方法が異なる。

私のタイムスタンプデータはどこかに送信されますか?

いいえ。すべての変換はブラウザ内のJavaScriptで実行。ページは入力した値をPOSTしない。DevToolsでネットワークタブを開いてタイムスタンプを変換、変換中に発信リクエストがゼロ表示される。タイムスタンプクレーム付きトークン、内部ログ行、またはホスト型サービスに貼り付けない他のものに対して安全。