UNIX タイムスタンプ コンバータ: エポック、タイムゾーン、および 57123 バグ

Laravel SaaS アプリの 1 つをユーザーが、定期購読更新日が「少し寛大に見えた」とメールで送信されたことがあります。請求ページは、彼の計画が今年の 4 月 25 日に更新されると彼に伝えました。 57123。

すべての個々の作品が正しかったので、このバグを見つけるのに恥ずかしいほど時間がかかりました。 React フロントエンドが送信しました Date.now()ーどっちが戻る ミリ秒ー そしてPHPのバックエンドはそうしました date('Y-m-d', $timestamp)、期待する 秒。 フィード 1740470400000 期待する関数に 1740470400 そして、あなたは約 55,000 年先の土地に着陸します。 例外でも、警告でも、テストに失敗しました。 ただ、顧客が、文明の熱死まで購読が本当に続いたかどうかを丁寧に尋ねています。

タイムスタンプは、ソフトウェアで最も退屈なトピックのようです。 実は、これは最も信頼できるバグ ファクトリーの 1 つです。秒数とミリ秒、UTC 対ローカル、DST トランジション、2038 ロールオーバーです。 ザ・ タイムスタンプ コンバーター Toolz.dev 上で、私は疲れてしまったので、存在します。 new Date(x * 1000) ブラウザ コンソールで 1 日 40 回。 このガイドは、私が今チェックしたことを、私がチェックする順序でカバーしています。

tl;dr: UNIX タイムスタンプは、1970-01-01T00:00:00 UTC からの秒数をカウントします。 10 桁 = 秒、13 桁 = ミリ秒ーそれらを混ぜると日付が55,000 年ずれます UTCを格納し、表示のためだけに変換し、のようなIANAゾーン名を使用します Asia/Dhaka 略語の代わりに。 タイムスタンプをすべてに貼り付けます タイムスタンプ コンバーター ISO 8601、RFC 2822、ローカル フォーム、および UTC フォームを取得するには、クライアント側で実行されるため、タイムスタンプがオフになります JWTS プロダクション ログは、ブラウザーから離れることはありません。

UNIX タイムスタンプとは正確には何ですか?

UNIX タイムスタンプ (エポック時間、POSIX タイム) は、経過した秒数です。 1970 年 1 月 1 日 00:00:00 UTCーthe "Unix epoch." It's a single integer, it has no timezone (it's always UTC by definition), and effectively every OS, language, and database understands it.最後のプロパティは、それが50 年を生き延びた理由です: それは誰も議論しない1 つの時間形式です。

なぜ1970 年か? 深い理由はありません - それは、Unixがベル研究所で構築されていたときに近い便利なラウンドデートでした、そして、初期のUnixは32 ビット整数で時間を数えました 任意の選択は、非常にUnixである普遍的な標準に化石化しました。

Sight で認識する価値のあるいくつかの参照ポイント:

4 行目は、微妙な理由で私のお気に入りの例です。多くのチュートリアル ページ リスト 1740470400 「2025 年 2 月 25 日 12:00:00」のように。 08:00 UTCー誰かがローカルタイムゾーンで一度変換し、それ以来間違った値がコピーペーストされている ブログ投稿ではなく、ツールでタイムスタンプを確認する この1 つを含む。

秒またはミリ秒 - どうやって伝えますか?

数字を数えます。 現在の時代の任意の日付:

• 10桁 (1740470400) - 秒。 Unixの規約、ほとんどのAPI、PHP& #39; s time()、Python' time.time() (フロートとして)、Stripe's API。
• 13桁 (1740470400000) - ミリ秒。 JavaScript' s Date.now()、Javas System.currentTimeMillis()、MongoDB の日付。

これは、私の 57123 年の更新日を正確に区別したものなので、失敗モードを詳しく説明します。

• MS は秒と解釈され、日付は ~55,000 年で 未来
• 秒数を ms → 日付で解釈する 1970 年 1 月 (すべてがエポックから約 3 週間以内に崩壊する)

もしあなたが署名 - 古代の日付か不条理な遠い未来の日付 - のどちらかを見たら、あなたは暗号の行を読む前にバグを知っているでしょう。 the タイムスタンプ コンバーター 数字のカウントを検出し、両方の解釈をラベル付けします。これにより、「これは S か MS?」引数が 2 秒で解決されます。

実際に知っておく必要がある日付形式はどれですか?

3 つをカバーするのは、開発者が触れるほとんどすべてのことです。

ISO 8601ー国際標準、APIやログで出すべきもの:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

キラー機能について 誰も言及していない: ISO 8601 文字列 時系列順に辞書順に並べ替える。 sort ログ ファイルで機能するだけです。 02/25/2026ースタイルフォーマット can't do that - and worse, US MM/DD そしてヨーロッパ人 DD/MM 毎月 12 日間は区別できません。

RFC 3339 (スペック) - ISO 8601 のインターネット プロトコル プロファイル。少し厳しく; API が発する場合 2026-07-13T09:30:45Z あなたは両方を満足させます。 これは標準化するフォーマットです。

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - 電子メールとHTTPヘッダー、RSSフィード。 書くよりも読む頻度が高い。

データベース形式は近接しています: MySQL DATETIME です 2026-07-13 09:30:45 (スペースのある ISO)、PostgreSQL timestamptz レンダリング 2026-07-13 09:30:45+00。

使用する言語はタイムスタンプをどのように処理しますか?

私自身のスタックからの 3 つと、それぞれに個人的に時間がかかった奇妙さがあります。

javascri (MS ONE):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

風変わり: すべてミリ秒で、 new Date(1740470400) 2025 年 2 月ではなく、1970 年 1 月 21 日に黙って提供します。 エラーなし。 この非対称性は、Web 開発で最も一般的なタイムスタンプ バグです。

php (秒の 1):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

癖： date() のフォーマット サーバー デフォルトのタイムゾーンなので、同じコードでマシンと本番環境で異なる日付が印刷されます。 あとー、 new DateTime('@1740470400') コンストラクターに渡すタイムゾーンを無視します @ フォームは常に UTC です。電話する必要があります setTimezone() 後。 WordPress は独自のレイヤーを追加します。 current_time('timestamp') 本物の UNIX タイムからの偽の「ローカル」タイムスタンプ オフセットを返します。これは、まさにその通りに聞こえる危険です。

パイソン:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

癖： fromtimestamp() なしで tz= ローカル時間で素朴な日時を返します。 ナイーブな日時は Python の時間のバグです。1 人が DST の境界を越えるまで、お互いに楽しく比較して減算します。 いつも合格 tz=; 使用 zoneinfo (3.9 以降の stdlib) 名前付きゾーンの場合。

気を失うことなくタイムゾーンをどのように処理すればよいでしょうか。

4 つのルールは、すべてが厄介な方法で学習しました。

1. UTC をストアします。 いつも。 UNIX タイムスタンプまたは timestamptz データベースで。 タイムゾーンは表示のみになります。
2. プレゼンテーション層で変換します。 ダッカのユーザーが見る +06:00、ベルリンのユーザーは、 +02:00、データベースはどちらも表示しません。
3. 略語ではなく、IANA 名を使用してください。 Asia/Dhaka、 America/New_York、 Europe/Berlin。 略語は曖昧である - CST は、who& #39;s の読み方 - および略語 don& #39;t が DST ルールをエンコードしていることに応じて、米国中部、中国標準時、またはキューバ標準時を意味します。 IANA の名前はそうです。
4. DST ロジックを手動でロールしないでください。 DST の日付は国によって異なり、法律によって変更され、一部の場所 (アリゾナ、バングラデシュ、日本) は DST をまったく観察していません。 IANA TZ データベースは、これが非常に難しいため存在します。それをラップするライブラリを使用してください。

ルール 1 の帰結: 2 つのシステムがイベント時間について意見が合わない場合、両方の値を UTC UNIX タイムスタンプに変換し、整数を比較します。 「でも、ここは午後 3 時と書かれています」に関する議論は即座に解消されます。

2038 年の問題は何ですか。気にする必要がありますか?

32 ビット符号付き整数は、次の場所で最大になります。 2,147,483,647。 UNIX のタイムスタンプとして、それは 2038 年 1 月 19 日 03:14:07 UTC。 1 秒後、値はマイナスで終了し、1901 年 12 月 13 日までになります。

遠くに聞こえる; それはisn& #39; t、2 つの理由のために。, it& #39; s約11.5 年私がこれを書くようにアウト - まあ組み込みシステムの寿命の内側, 産業用コントローラ, そしてその1 つのレガシーサービス誰も触れたくない.2 番目 未来 15 年の住宅ローンのスケジュールまたは 20 年の証明書の有効期限を計算するシステム 2038 今日はね。 MySQL です TIMESTAMP 列のタイプは古典的なトラップです - it' s 32 ビット境界と can' t ストアの日付は 2038-01-19 を超えています DATETIME 同じデータベースで問題ありません。

64 ビットで安全です time_t (最新の OS)、JavaScript (Float64 ミリ秒)、Python (任意の精度)、PostgreSQL。 32 ビットの組み込みシステムでは、あなたは危険にさらされています。 TIMESTAMP 列、およびハードコードされた C コード int32_t 時間。 テストは簡単です: プッシュ 2147483648 (限界を超えて) パイプラインを通り抜け、何が出てくるか見てみましょう。 ザ・ タイムスタンプ コンバーター 2038 年以降のテスト値を喜んで生成します。

実際のデバッグではタイムスタンプはどこに表示されますか?

JWT の有効期限。 トークンが運ぶ iat あんど exp UNIX 秒としてのクレーム:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

「なぜこのユーザーがログアウトしたの?」は、変換することによって答えられます。 exp。 でトークンをデコードします。 JWT デコーダ そして、クレームを変換します。どちらもクライアント側で実行します。貼り付けられたトークンはライブ資格情報 (the) であるため、これは重要です データ プライバシー ガイド サーバー側のツールにトークンを入れることを拒否する理由について説明します)。

ログの相関。 1 つのインシデント、3 つのサービス、3 つのフォーマット: Nginx ログ [13/Jul/2026:09:30:45 +0000]アプリは ISO 8601 をログに記録します。キュー ワーカーは生のエポック秒数を記録します。 すべてを 1 つの形式に変換することは、タイムラインを構築するためのステップ 0 です。

API 統合。 ストライプ送信 "created": 1740470400 (秒)。 JavaScript で構築された API が送信する 1740470400000 (ms). Google API は RFC 3339 文字列を送信します.3 つすべてを消費すると,変換 isn't occasional - it's constant.でペイロードをフォーマットします. JSON フォーマッタ そして興味深いフィールドを変換します。

日付範囲クエリ。 WHERE created_at >= 1752364800 AND created_at < 1752451200ーその日が正しいか?両方の境界を変換して、チェック、 UTCで、削除を実行する前に。 関連: 日付差分計算 「この 2 つの間の日数は?」 タイムゾーン コンバーター 会議時間の計算、そして クロンパーサー 「このスケジュールはいつ実際に発生するの?」

よくある質問

UNIX タイムスタンプとは何ですか?

1970 年 1 月 1 日 00:00:00 UTC (Unix 時代) 以降の経過秒数。定義上、タイムゾーンに依存しません。同じ瞬間は地球上のどこでも同じ数です。そのため、it' はオペレーティング システム、言語、データベース間の標準交換形式です。

タイムスタンプが 10 桁で、他のタイムスタンプが 13 個あるのはなぜですか?

10 桁は秒 (標準の UNIX 規則、PHP、ほとんどの API)、13 桁はミリ秒 (JavaScript'S) です。 Date.now()、ジャワ）。 1,000 で割ると、ms から seconds になります。 2 つのシフトが混乱するのは、1970 年 1 月に 55,000 年後の日付またはさかのぼるものです。

UNIX のタイムスタンプは 1970 年以前の日付を表すことができますか?

はい - 負の値は時代から逆算されます。 -86400 1969 年 12 月 31 日です。 32 ビットの署名入りタイムスタンプは 1901 年 12 月 13 日までさかのぼります。 ただし、一部のシステムや API は、タイムスタンプが否定的であるため、それらに依存する前にテストしてください。

2038年の問題は何ですか?

32 ビット署名タイムスタンプは 2,147,483,647 でオーバーフロー - 2038 年 1 月 19 日、03:14:07 UTC - 1901 年 12 月のラッピング。最新の 64 ビット システムは影響を受けませんが、32 ビット組み込みデバイス、レガシー C コード、MySQL は影響を受けます TIMESTAMP 列が公開されます。 遠い将来の日付 (住宅ローン、証明書) を計算するシステムは、2038 年に登場する何年も前にバグに遭遇しました。

なぜ私の日付が 1970 年 1 月に表示されるのですか?

ゼロまたはゼロに近いタイムスタンプがフォーマット コードに達しました。通常、初期化されていない値、0 を返す解析の失敗、またはミリ秒が予想される秒数。画面上の 1970 年の日付は、データ ポイントになることはほとんどありません。 it's はコスチュームを着たヌルです。

タイムスタンプまたは日時文字列をデータベースに保存する必要がありますか?

UTCをどちらにしろ格納する - 型はタイムゾーンの規律よりも重要ではない Unix整数はコンパクトで、自明にソートし、完全に構文解析を回避する; timestamptz/DATETIME 列はクエリ結果で人間が読み取り可能であり、SQL で日付算術をサポートしています。行ってはいけないのは、オフセットなしでローカル時間を保存することです。that's データ損失は、次の DST 移行時にのみ発見されます。

うるう秒の影響はエポックですか?

実際には、いいえ。 Unix 時間はうるう秒のふりをします。don't 存在します。毎日は正確に 86,400 秒で、システムは通常、うるう秒が発生すると時計を塗抹したりステップしたりします。アプリケーションコードにとって、これは問題ではありません。科学的なタイミングの文脈でのみ重要であり、TAI または GPS 時間が代わりに使用されます。

生産ログのタイムスタンプをオンライン コンバーターに貼り付けても安全ですか?

生のタイムスタンプだけではほとんど明らかになりませんが、タイムスタンプは通常、コンテキスト (ユーザー ID、トークン クレーム、ログ行) とともに移動します。 タイムスタンプ コンバーター Toolz.dev では、データが送信されずにブラウザーで完全に変換されるため、本番ログや JWTS から直接値を貼り付けても何も公開されません。

UNIX のタイムスタンプを読み取り可能な日付に変換するにはどうすればよいですか?

数値をコンバーターに貼り付けて、UTC とローカルの結果を読み取るか、コードで実行します。 new Date(ts * 1000).toISOString() JavaScript では、 datetime.fromtimestamp(ts, tz=timezone.utc) Pythonで、 date -u -d @ts linuxで。 最初に正しく理解すべきことは、値が秒単位かミリ秒単位かということです。他のすべてはそこから導き出されます。

現在の UNIX タイムスタンプを取得するにはどうすればよいですか?

date +%s シェルで、 Math.floor(Date.now() / 1000) JavaScript では、 int(time.time()) Pythonで、 SELECT EXTRACT(EPOCH FROM NOW()) PostgreSQL で。 JavaScript は奇妙なものであることに注意してください。 Date.now() ミリ秒を返します。したがって、除算はオプションではありません。