Unix エポック タイム コンバーター & Discord タイムスタンプ ジェネレーター

Unix エポック タイムスタンプを人間が判読できる日付に変換したり、その逆の変換を行ったりします。コピー＆ペースト可能な Discord タイムスタンプをリアルタイムで生成します。

リアルタイムUnixエポック時間
秒 0000000000
ミリ秒 0000000000000
ローカル時間
-
UTC時間
-
Unix Epoch (sec)
-
Unix Epoch (ms)
-
相対時間
-
複数タイムゾーン時間軸比較 Slide this handle to synchronize and visually compare the local and UTC dates and times across all selected timezones in real time.

時間軸スライダーを動かして、複数のタイムゾーンの時間を視覚的に比較できます。

-12h -6h UTC (0) +6h +12h 

                                
                            

                        

                    

                

                
                

分散データベース システムの同期、アプリケーション イベントのログ記録、API ペイロードのデバッグには、高精度で標準化された時間を追跡する方法が必要です。 Unix エポック時間を標準化することで、1970 年 1 月 1 日から経過した正確な秒数を表す、タイムゾーンに依存しない不変の整数が提供されます。この包括的なガイドでは、Unix タイムスタンプの仕組みを詳しく説明し、最新の環境全体でのプログラムによる変換方法を示し、Discord スノーフレーク ID などの代替時間構造を解析する方法を説明します。



Unix エポック時間とタイムスタンプのダイナミクスを理解する



Unix 時間 (Unix エポック、POSIX 時間、または Unix タイムスタンプとも呼ばれます) は、増分する整数として時系列の進行状況を追跡します。これは、1970 年 1 月 1 日、00:00:00 UTC (ISO 8601 表現: 1970-01-01T00:00:00Z) の基準点からの経過秒数を表します。このエポックのまさに瞬間、カウンターはちょうど 0 でした。




エポック タイムスタンプはタイムゾーンに厳密に依存しません。この整数は世界中で単一の普遍的な瞬間を表し、ローカル クライアント アプリケーションは特定の UTC オフセットを適用することでプレゼンテーション層を調整します。タイムゾーン マッピングがどのように機能するかを確認するには、タイムスタンプ 1577923200 のローカル解釈を比較します。




    

        
            

                タイムゾーン地域
                ローカライズされた日付と時刻
                オフセット値
            

        
        
            

                GMT / UTC
                2020年1月2日木曜日、00:00:00
                UTC+00:00
            

            

                インド (コルカタ)
                2020年1月2日木曜日、05時30分00秒
                UTC+05:30
            

            

                アメリカ（ニューヨーク）
                2020年1月1日水曜日、19時0分00秒
                UTC-05:00
            

        
    





Unix 時間ではうるう秒は考慮されません。代わりに、各暦日には正確に 86,400 秒が含まれると想定します。うるう秒はカウンタでは無視されるため（前の秒とまったく同じタイムスタンプ値を共有する）、Unix エポック時間は、長い地質学的スパンにわたって協定世界時 (UTC) との完全で線形な同期を維持しません。開始しきい値の 1970 年 1 月 1 日より前の日付の場合、システムは負の整数値を使用します (たとえば、-86400 は 1969 年 12 月 31 日の 00:00:00 UTC を示します)。




データベース モデリングやバックグラウンド ワーカー タスクでこれらの数値を扱う場合、開発者は固定の時系列間隔に依存します。次のリストは、標準単位を秒単位の正確な値にマッピングします。



    
    
  • 1 時間: 3,600 秒
    • 
    
  • 1 日: 86,400 秒
    • 
    
  • 1 週間: 604,800 秒
    • 
    
  • 1 か月 (30.44 日として計算): 2,629,743 秒
    • 
    
  • 1 年 (365.24 日として計算): 31,556,926 秒
    • 




これらの値を使用して継続時間の値を直接計算すると、cron スケジュールの処理、JWT トークンの有効期限切れ、または NoSQL データベースでのカスタム TTL インデックスの構築が簡単になります。



秒とミリ秒: 桁精度のナビゲート



最新のソフトウェアのタイムスタンプは、アプリケーションの要件に応じてさまざまなレベルの精度で実行されます。ほとんどのシステム設計では、次の 4 つの解像度のいずれかを使用します。



    
    
  1. 秒 (10 桁形式): 例: 1735689600。これは、Python、PHP、リレーショナル データベース (PostgreSQL や MySQL など)、および Linux シェル環境で使用される標準解像度です。
    2. 
    
  2. ミリ秒 (13 桁形式): 例: 1735689600000。この形式は、JavaScript、Java、および最新の JSON ベースの Web API の大部分で標準です。
    3. 
    
  3. マイクロ秒 (16 桁形式): 例: 1735689600000000。通常、高精度のトレース、システム ロギング、および低レベルの診断プラットフォーム用に予約されています。
    4. 
    
  4. ナノ秒 (19 桁形式): 特殊なカーネル レベルのトレース システムおよびリアルタイム処理ネットワークで使用されます。
    5. 




秒をミリ秒に変換するには、整数値に 1,000 を掛けます。逆に、ミリ秒を標準の秒に変換するには、整数を 1,000 で除算して末尾の桁を削除します。




ランドマークおよびシーケンシャルな Unix タイムスタンプを理解すると、時系列の進行とスケールについて明確な視点が得られます。




     




    

        
            

                Unix タイムスタンプ
                同等の UTC 日付と時刻
                マイルストーンのコンテキスト
            

        
        
            

                0
                1970 年 1 月 1 日木曜日、00:00:00 UTC
                Unixの時代
            

            

                10億
                2001 年 9 月 9 日日曜日、01:46:40 UTC
                10 億分の 2 番目のマイルストーン
            

            

                1,234,567,890
                2009 年 2 月 13 日金曜日、23:31:30 UTC
                連続した 10 進数の桁数の進行
            

            

                1,735,689,600
                2025 年 1 月 1 日水曜日、00:00:00 UTC
                2025 年の始まり
            

            

                20億
                2033 年 5 月 18 日火曜日、03:33:20 UTC
                20 億分の 2 番目のマイルストーン
            

            

                2,147,483,647
                2038 年 1 月 19 日火曜日、03:14:07 UTC
                絶対最大の符号付き 32 ビット制限
            

        
    




2038 年問題: 32 ビット システムが失敗する理由



Unix タイムスタンプを符号付き 32 ビット整数として保存するレガシー システム、組み込みファームウェア、およびデータベース スキーマは、最終的にオーバーフロー制限に遭遇します。符号付き 32 ビット整数には、2,147,483,647 までの値しか格納できません。正確な限界点は 2038 年 1 月 19 日、03:14:07 UTC に発生します。




システム クロックの次のティック (03:14:08 UTC) で、整数カウンターがオーバーフローし、負の最小値 -2,147,483,648 に戻ります。この移行を処理できないシステムは、日付を 1901 年 12 月 13 日 として解釈します。これにより、システムのクラッシュ、証明書の無効化、ファイル システム エラー、データベース クエリの破損が引き起こされます。



Unix タイムスタンプを変換および生成するためのプログラムによるメソッド



開発者が現在時刻を取得して変換を実行できるように、以下の表に、標準エポック タイムスタンプを取得し、さまざまな言語やプラットフォームで一般的な値 (1800000000 を参照として使用) を現地時刻に変換する方法の概要を示します。




                                                  




    

        
            

                言語 / プラットフォーム
                現在のエポック (秒)
                エポックを日付に変換
            

        
        
            

                JavaScript
                Math.floor(Date.now() / 1000)
                新しい日付(1800000000 * 1000).toLocaleString()
            

            

                パイソン
                int(時間.時間())
                time.ctime(1800000000)
            

            

                ジャワ
                Instant.now().getEpochSecond()
                new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new Date(1800000000L * 1000))
            

            

                行く
                time.Now().Unix()
                time.Unix(1800000000, 0)
            

            

                PHP
                時間（）
                日付('r', 1800000000)
            

            

                ルビー
                今から私までの時間
                時刻.at(1800000000)
            

            

                C#
                DateTimeOffset.Now.ToUnixTimeSeconds()
                DateTimeOffset.FromUnixTimeSeconds(1800000000).LocalDateTime
            

            

                C++
                duration_cast<秒>(system_ Clock::now().time_since_epoch()).count()
                —
            

            

                さび
                SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
                —
            

            

                パール
                時間
                スカラーローカル時間(1800000000)
            

            

                PostgreSQL
                SELECT EXTRACT(今からのエポック());
                SELECT TO_TIMESTAMP(1800000000);
            

            

                MySQL
                SELECT UNIX_TIMESTAMP(NOW());
                SELECT FROM_UNIXTIME(1800000000);
            

            

                SQLサーバー
                SELECT DATEDIFF(SECOND, '1970-01-01', GETUTCDATE());
                SELECT DATEADD(SECOND, 1800000000, '1970-01-01');
            

            

                SQLite
                SELECT unixepoch();
                SELECT datetime(1800000000, 'unixepoch');
            

            

                Unix / Linux シェル
                日付 +%s
                日付 -ud @1800000000
            

            

                macOS
                日付 +%s
                日付 -j -r 1800000000
            

            

                パワーシェル
                [DateTimeOffset]::Now.ToUnixTimeSeconds()
                [DateTimeOffset]::FromUnixTimeSeconds(1800000000).LocalDateTime
            

            

                Excel / シート
                —
                =(A1 / 86400) + 25569
            

        
    




カスタム エポックと Discord スノーフレーク タイムスタンプ ジェネレーター



さまざまなアーキテクチャでは、特殊な参照エポックが使用され、ハードウェア プラットフォーム、データベース、またはアプリケーションの仕様に応じて解像度が増加します。これらの形式には次のようなものがあります。



    
    
  • LDAP タイムスタンプ: 1601 年 1 月 1 日から始まる 100 ナノ秒ブロックでカウントされます。
    • 
    
  • .NET DateTime Ticks: グレゴリオ暦 1 年から始まる 100 ナノ秒ブロック単位でカウントします。
    • 
    
  • Chrome/WebKit タイムスタンプ: 1601 年 1 月 1 日からマイクロ秒単位でカウントされます。
    • 
    
  • Mac HFS+: 1904 年 1 月 1 日から秒単位でカウントされます。
    • 
    
  • NTP タイムスタンプ: 1900 年 1 月 1 日から始まる秒数でカウントされます。
    • 
    
  • GPS 時間: 1980 年 1 月 6 日から始まる秒数と週数でカウントされます。
    • 
    
  • SAS タイムスタンプ: 1960 年 1 月 1 日から開始して秒または日単位でカウントします。
    • 
    
  • Cocoa Core Data: 2001 年 1 月 1 日から始まる秒単位でカウントされます。
    • 
    
  • Excel OADate: 1900 年 1 月 1 日から小数日でカウントされます。
    • 
    
  • FAT タイムスタンプ: 1980 または 2000 から始まる秒単位でカウントします。
    • 
    
  • ユリウス日: 古代の天文基準点からの時系列的な進行を日数で測定します。
    • 
    
  • Snowflake ID: Discord と Twitter (X) で使用される分散型タイムスタンプ インデックス形式。
    • 



Discord のタイムスタンプとスノーフレーク ID について



Discord は、メッセージ、チャネル、サーバー、ユーザーなどのオブジェクトを識別するために、一意の分散型 64 ビット符号なし整数 (スノーフレーク ID) を生成します。標準の増分整数やオーバーヘッドの高い UUID とは異なり、Discord スノーフレークは ID 自体の中に正確な作成時刻を埋め込むため、分散システムのパフォーマンスに役立ちます。




Discord スノーフレーク ID の構造は、次の 4 つの異なるコンポーネントに分かれています。



    
    
  • タイムスタンプ (42 ビット): カスタム Discord エポック (2015 年 1 月 1 日、00:00:00 UTC に設定、Unix タイムスタンプ 1420070400000 に相当) から経過したミリ秒を表します。
    • 
    
  • ワーカー ID (5 ビット): 内部サーバーのワーカー インデックスを表します。
    • 
    
  • プロセス ID (5 ビット): 内部プロセスのインデックスを表します。
    • 
    
  • インクリメント (12 ビット): プロセスごとにミリ秒ごとに 0 にリセットされるシーケンシャル カウンタ。
    • 




表示しているユーザーのローカル タイムゾーンに自動的に調整される Discord メッセージに判読可能な日付を表示するには、開発者は Discord タイムスタンプ ジェネレーターを使用します。標準の Unix タイムスタンプをこれらのジェネレーターに入力すると、フォーマットされたマークダウン文字列が生成されます。以下の表に、使用可能なスタイル形式を示します。




       




                    

                        
                            

                                マークダウン構文
                                出力例 (Unix 1735689600 の場合)
                                表示スタイルの説明
                            

                        
                        
                            

                                <t:1735689600:t>
                                00:00
                                短時間
                            

                            

                                <t:1735689600:T>
                                00:00:00
                                長い間
                            

                            

                                <t:1735689600:d>
                                2025/01/01
                                ショートデート
                            

                            

                                <t:1735689600:D>
                                2025 年 1 月 1 日
                                ロングデート
                            

                            

                                <t:1735689600:f>
                                2025年1月1日 00:00
                                短い日付/時間
                            

                            

                                <t:1735689600:F>
                                2025年1月1日（水）00:00
                                長い日付/時刻
                            

                            

                                <t:1735689600:R>
                                5年後 / 5年前
                                相対時間
                            

                        
                    

                


分散システムにおける時間ワークフローの最適化



最新の分散システム内で時間計算を管理するには、タイムゾーンのずれ、ペイロード サイズのバグ、オーバーフロー クラッシュを防ぐための標準化されたアプローチが必要です。標準 Unix エポックでデータベース構造を標準化すると、時間操作タスクが簡素化され、マイクロサービスと外部インターフェイス全体で一貫した操作が保証されます。




API を設計するとき、またはメッセージ キューを構成するときは、次の 3 つのガイドラインに留意してください。



    
    
  1. 時刻を UTC またはエポック整数形式で保存します: 永続化レイヤーをローカル タイムゾーン オフセットからクリーンな状態に保ちます。ローカリゼーションをプレゼンテーション層のみに適用します。
    2. 
    
  2. 64 ビット表現を優先する: データベース列を設計するとき、またはプログラミング構造を選択するときは、2038 年のランタイム オーバーフローを防ぐために 32 ビット型から移行してください。
    3. 
    
  3. 適切な精度を選択してください: システム仕様に一致させます (例: API イベントにはミリ秒を使用し、分散ロック取得をトレースする場合にのみナノ秒を使用します)。
    4. 




ブラウザ ユーティリティを使用してタイムスタンプを変換したり、エポックをチェックしたりする場合、セキュリティとプライバシーが最も重要です。 Toolsaur の変換ツールは、「すべての処理はブラウザ内でローカルに実行されます。データは決して当社のサーバーに送信されません。」という哲学を直接実装しています。これにより、データベースのタイムスタンプを含む機密システム ログがサードパーティのエンドポイントに漏洩しないことが保証されます。



エポックコンバーターに関するよくある質問


Unix タイムスタンプがタイムゾーンに依存しないのはなぜですか?



Unix タイムスタンプは、単一のグローバル参照点 (1970 年 1 月 1 日、00:00:00 UTC) からの絶対経過時間を表します。この参照開始点は地理的位置に関係なく同一であるため、計算されたタイムスタンプ整数は同じままです。ローカル タイムゾーン調整は、クライアント インターフェイス内でタイムスタンプを人間が判読できる日付文字列にフォーマットする場合にのみ適用されます。



10 桁のタイムスタンプと 13 桁のタイムスタンプの違いは何ですか?



10 桁のタイムスタンプは秒単位の精度を表します (1735689600 など)。これは、POSIX オペレーティング システム、Python、SQL データベースで一般的です。 13 桁のタイムスタンプはミリ秒単位の精度を表します (1735689600000 など)。これは、JavaScript ランタイム、Java、および最新の REST API の標準です。それらの間を移動するには、1,000 を乗算または除算する必要があります。



2038 年問題は現代のデータベースにどのような影響を与えるのでしょうか?



データベース列に符号付き 32 ビット整数データ型 (古いデータベース スキーマの INT など) を使用して Unix タイムスタンプが格納されている場合、2038 年 1 月 19 日 03:14:07 UTC を超えるタイムスタンプを持つレコードはオーバーフローを引き起こします。これにより、数値が負の値にラップされ、将来の日付が 1901 年 12 月 13 日として解釈されます。システムは、これらの列を符号付き 64 ビット整数 (BIGINT) に移行する必要があります。



Unix 時間はうるう秒をどのように処理しますか?



Unix 時間ではうるう秒は考慮されず、毎日がちょうど 86,400 秒であると想定されます。うるう秒が発生すると、Unix タイムスタンプが繰り返されるか、1 秒間停止します。この設計の選択により、計算計算が簡素化されますが、正確な協定世界時 (UTC) タイムラインからのわずかなずれが発生します。



Discord スノーフレーク ID とは何ですか? 標準の Unix タイムスタンプとの違いは何ですか?



Discord スノーフレーク ID は、サーバー アーキテクチャのメタデータ (ワーカー ID、プロセス ID、およびローカル インクリメント) とともに作成タイムスタンプをエンコードするカスタムの 64 ビット符号なし整数です。秒単位の標準的な 10 桁の Unix タイムスタンプとは異なり、スノーフレーク ID は 2015 年 1 月 1 日から始まるカスタム エポックを使用し、ミリ秒単位で間隔を追跡し、この高精度時間を ID の最初の 42 ビットに保存します。



Microsoft Excel でエポック タイムスタンプを変換するにはどうすればよいですか?



Excel は、1900 年 1 月 1 日からの経過日数として日付を追跡します。セル A1 の標準の 10 桁の Unix タイムスタンプ (秒) を Excel で読み取り可能な日付に変換するには、式 =(A1 / 86400) + 25569 を適用します。ここで、86400 は 1 日の秒数、25569 は Excel のエポックと Unix エポックの間の日数単位のオフセットです。出力を表示するには、セルの書式設定を「日付」または「時刻」に設定します。