Unix-Epochenzeitkonverter und Discord-Zeitstempelgenerator

Konvertieren Sie Zeitstempel der Unix-Epoche in für Menschen lesbare Daten und umgekehrt. Generieren Sie kopier- und einfügbare Discord-Zeitstempel in Echtzeit.

Echtzeit-Unix-Epoche
Sekunden 0000000000
Millisekunden 0000000000000
Lokale Zeit
-
UTC-Zeit
-
Unix Epoch (sec)
-
Unix Epoch (ms)
-
Relative Zeit
-
Zeitzonen-Timeline-Vergleich Slide this handle to synchronize and visually compare the local and UTC dates and times across all selected timezones in real time.

Verschieben Sie die Timeline, um Zeiten in mehreren Zeitzonen visuell zu vergleichen.

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

                                
                            

                        

                    

                

                
                

Die Synchronisierung verteilter Datenbanksysteme, die Protokollierung von Anwendungsereignissen und das Debuggen von API-Nutzlasten erfordern eine hochpräzise, ​​standardisierte Methode zur Zeitverfolgung. Durch die Standardisierung auf die Unix-Epochenzeit wird eine unveränderliche, von der Zeitzone unabhängige Ganzzahl bereitgestellt, die die genaue Anzahl der seit dem 1. Januar 1970 verstrichenen Sekunden darstellt. Dieser umfassende Leitfaden beschreibt detailliert die Mechanik von Unix-Zeitstempeln, demonstriert programmgesteuerte Konvertierungsmethoden in modernen Umgebungen und erklärt, wie alternative Zeitstrukturen wie Discord-Schneeflocken-IDs analysiert werden.



Verständnis der Unix-Epochenzeit und der Zeitstempeldynamik



Die Unix-Zeit (auch bekannt als Unix-Epoche, POSIX-Zeit oder Unix-Zeitstempel) verfolgt den chronologischen Fortschritt als aufsteigende Ganzzahl. Es stellt die Anzahl der verstrichenen Sekunden seit dem Referenzpunkt 1. Januar 1970, 00:00:00 UTC dar (ISO 8601-Darstellung: 1970-01-01T00:00:00Z). Zum genauen Zeitpunkt dieser Epoche stand der Zähler bei genau 0.




Epochenzeitstempel sind strikt zeitzonenunabhängig. Die Ganzzahl stellt einen einzelnen universellen Zeitpunkt auf der ganzen Welt dar, und lokale Clientanwendungen passen die Präsentationsschicht an, indem sie bestimmte UTC-Offsets anwenden. Um zu sehen, wie die Zeitzonenzuordnung funktioniert, vergleichen Sie lokale Interpretationen des Zeitstempels 1577923200:




    

        
            

                Zeitzonenregion
                Lokalisiertes Datum und Uhrzeit
                Offsetwert
            

        
        
            

                GMT / UTC
                Donnerstag, 2. Januar 2020, 00:00:00
                UTC+00:00
            

            

                Indien (Kalkutta)
                Donnerstag, 2. Januar 2020, 05:30:00
                UTC+05:30
            

            

                Amerika (New York)
                Mittwoch, 1. Januar 2020, 19:00:00
                UTC-05:00
            

        
    





Die Unix-Zeit berücksichtigt keine Schaltsekunden. Stattdessen wird davon ausgegangen, dass jeder Kalendertag genau 86.400 Sekunden enthält. Da Schaltsekunden im Zähler ignoriert werden (sie haben genau den gleichen Zeitstempelwert wie die vorhergehende Sekunde), gewährleistet die Unix-Epochenzeit über lange geologische Zeiträume hinweg keine perfekte, lineare Synchronisierung mit der koordinierten Weltzeit (UTC). Für Daten vor dem Startschwellenwert 1. Januar 1970 verwendet das System negative Ganzzahlwerte (z. B. -86400 bezeichnet den 31. Dezember 1969, 00:00:00 UTC).




Um mit diesen Zahlen in der Datenbankmodellierung oder bei Hintergrundarbeitsaufgaben zu arbeiten, verlassen sich Entwickler auf feste chronologische Intervalle. Die folgende Liste ordnet Standardeinheiten ihre genauen Werte in Sekunden zu:



    
    
  • 1 Stunde: 3.600 Sekunden
    • 
    
  • 1 Tag: 86.400 Sekunden
    • 
    
  • 1 Woche: 604.800 Sekunden
    • 
    
  • 1 Monat (berechnet bei 30,44 Tagen): 2.629.743 Sekunden
    • 
    
  • 1 Jahr (berechnet bei 365,24 Tagen): 31.556.926 Sekunden
    • 




Die direkte Berechnung von Dauerwerten mit diesen Werten erleichtert die Handhabung von Cron-Zeitplänen, das Ablaufen von JWT-Tokens oder die Erstellung benutzerdefinierter TTL-Indizes in NoSQL-Datenbanken.



Sekunden vs. Millisekunden: Navigierende Ziffernpräzision



Zeitstempel in moderner Software werden je nach Anwendungsanforderungen mit unterschiedlicher Präzision ausgeführt. Die meisten Systemdesigns nutzen eine dieser vier Auflösungen:



    
    
  1. Sekunden (10-stelliges Format): Z. B. 1735689600. Dies ist die Standardauflösung, die von Python, PHP, relationalen Datenbanken (wie PostgreSQL und MySQL) und Linux-Shell-Umgebungen verwendet wird.
    2. 
    
  2. Millisekunden (13-stelliges Format): Z. B. 1735689600000. Dieses Format ist Standard in JavaScript, Java und den meisten modernen JSON-basierten Web-APIs.
    3. 
    
  3. Mikrosekunden (16-stelliges Format): Z. B. 1735689600000000. Normalerweise für hochpräzise Ablaufverfolgung, Systemprotokollierung und Low-Level-Diagnoseplattformen reserviert.
    4. 
    
  4. Nanosekunden (19-stelliges Format): Wird in speziellen Trace-Systemen auf Kernel-Ebene und Echtzeit-Verarbeitungsnetzwerken verwendet.
    5. 




Um Sekunden in Millisekunden umzurechnen, multiplizieren Sie den ganzzahligen Wert mit 1.000. Um umgekehrt Millisekunden wieder in Standardsekunden umzuwandeln, wenden Sie eine ganzzahlige Division durch 1.000 an, um die nachfolgenden Ziffern zu entfernen.




Das Verständnis von Meilensteinen und sequentiellen Unix-Zeitstempeln bietet einen klaren Überblick über den chronologischen Verlauf und die Skalierung:




     




    

        
            

                Unix-Zeitstempel
                Äquivalentes UTC-Datum und -Uhrzeit
                Meilensteinkontext
            

        
        
            

                0
                Donnerstag, 1. Januar 1970, 00:00:00 UTC
                Die Unix-Epoche
            

            

                1.000.000.000
                Sonntag, 9. September 2001, 01:46:40 UTC
                Der einmilliardste zweite Meilenstein
            

            

                1.234.567.890
                Freitag, 13. Februar 2009, 23:31:30 UTC
                Sequentielle Dezimalstellenfolge
            

            

                1.735.689.600
                Mittwoch, 1. Januar 2025, 00:00:00 UTC
                Beginn des Jahres 2025
            

            

                2.000.000.000
                Dienstag, 18. Mai 2033, 03:33:20 UTC
                Zweimilliardster zweiter Meilenstein
            

            

                2.147.483.647
                Dienstag, 19. Januar 2038, 03:14:07 UTC
                Die absolute maximale vorzeichenbehaftete 32-Bit-Grenze
            

        
    




Das Jahr-2038-Problem: Warum 32-Bit-Systeme scheitern



Ältere Systeme, eingebettete Firmware und Datenbankschemata, die Unix-Zeitstempel als signierte 32-Bit-Ganzzahlen speichern, werden irgendwann auf ein Überlauflimit stoßen. Eine vorzeichenbehaftete 32-Bit-Ganzzahl kann nur Werte bis zu 2.147.483.647 speichern. Der genaue Bruchpunkt liegt am 19. Januar 2038 um 03:14:07 UTC.




Beim nächsten Tick der Systemuhr (03:14:08 UTC) läuft der Ganzzahlzähler über und erreicht seinen minimalen negativen Grenzwert von -2,147,483,648. Systeme, die diesen Übergang nicht bewältigen, interpretieren das Datum als 13. Dezember 1901. Dies führt zu Systemabstürzen, ungültigen Zertifikaten, Dateisystemfehlern und beschädigten Datenbankabfragen.



Programmgesteuerte Methoden zum Konvertieren und Generieren von Unix-Zeitstempeln



Um Entwicklern dabei zu helfen, die aktuelle Zeit zu erfassen und Konvertierungen durchzuführen, werden in der folgenden Tabelle Methoden zum Abrufen von Standard-Epochenzeitstempeln und zum Konvertieren eines generischen Werts (unter Verwendung von 1800000000 als Referenz) zurück in lokale Zeiten in verschiedenen Sprachen und Plattformen beschrieben.




                                                  




    

        
            

                Sprache / Plattform
                Aktuelle Epoche (Sekunden)
                Konvertieren Sie die Epoche in das Datum
            

        
        
            

                JavaScript
                Math.floor(Date.now() / 1000)
                neues Datum(1800000000 * 1000).toLocaleString()
            

            

                Python
                int(time.time())
                time.ctime(1800000000)
            

            

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

            

                Gehen
                time.Now().Unix()
                Zeit.Unix(1800000000, 0)
            

            

                PHP
                Zeit()
                Datum('r', 1800000000)
            

            

                Rubin
                Time.now.to_i
                Zeit.at(1800000000)
            

            

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

            

                C++
                Duration_cast(system_clock::now().time_since_epoch()).count()
                —
            

            

                Rost
                SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
                —
            

            

                Perl
                Zeit
                Skalare Ortszeit (1800000000)
            

            

                PostgreSQL
                SELECT EXTRACT(EPOCH FROM now());
                SELECT TO_TIMESTAMP(1800000000);
            

            

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

            

                SQL-Server
                SELECT DATEDIFF(SECOND, '1970-01-01', GETUTCDATE());
                SELECT DATEADD(SECOND, 1800000000, '1970-01-01');
            

            

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

            

                Unix-/Linux-Shell
                Datum +%s
                Datum -ud @1800000000
            

            

                macOS
                Datum +%s
                Datum -j -r 1800000000
            

            

                PowerShell
                [DateTimeOffset]::Now.ToUnixTimeSeconds()
                [DateTimeOffset]::FromUnixTimeSeconds(1800000000).LocalDateTime
            

            

                Excel / Tabellen
                —
                =(A1 / 86400) + 25569
            

        
    




Benutzerdefinierte Epochen und Discord-Schneeflocken-Zeitstempelgeneratoren



Verschiedene Architekturen verwenden je nach Hardwareplattform, Datenbank oder Anwendungsspezifikationen spezielle Referenzepochen und Inkrementauflösungen. Einige dieser Formate umfassen:



    
    
  • LDAP-Zeitstempel: Zählt in 100-Nanosekunden-Blöcken ab dem 1. Januar 1601.
    • 
    
  • .NET DateTime Ticks: Zählt in 100-Nanosekunden-Blöcken ab dem gregorianischen Jahr 1.
    • 
    
  • Chrome/WebKit-Zeitstempel: Zählt in Mikrosekunden ab dem 1. Januar 1601.
    • 
    
  • Mac HFS+: Zählt in Sekunden ab dem 1. Januar 1904.
    • 
    
  • NTP-Zeitstempel: Zählt in Sekunden ab dem 1. Januar 1900.
    • 
    
  • GPS-Zeit: Zählt in Sekunden und Wochen ab dem 6. Januar 1980.
    • 
    
  • SAS-Zeitstempel: Zählt in Sekunden oder Tagen ab dem 1. Januar 1960.
    • 
    
  • Kakao-Kerndaten: Zählt in Sekunden ab dem 1. Januar 2001.
    • 
    
  • Excel OADate: Zählt in Bruchteilen von Tagen ab dem 1. Januar 1900.
    • 
    
  • FAT-Zeitstempel: Zählt in Sekunden ab 1980 oder 2000.
    • 
    
  • Julianischer Tag: Misst den chronologischen Fortschritt in Tagen ausgehend von alten astronomischen Referenzpunkten.
    • 
    
  • Snowflake-ID: Ein dezentrales Zeitstempel-Indizierungsformat, das von Discord und Twitter (X) verwendet wird.
    • 



Discord-Zeitstempel und Schneeflocken-IDs verstehen



Discord generiert einzigartige, dezentrale 64-Bit-Ganzzahlen ohne Vorzeichen (Snowflake-IDs), um Objekte wie Nachrichten, Kanäle, Server und Benutzer zu identifizieren. Im Gegensatz zu standardmäßigen inkrementierenden Ganzzahlen oder UUIDs mit hohem Overhead bettet eine Discord-Schneeflocke die genaue Erstellungszeit in die ID selbst ein, was die Leistung in verteilten Systemen verbessert.




Die Struktur einer Discord-Snowflake-ID ist in vier verschiedene Komponenten unterteilt:



    
    
  • Zeitstempel (42 Bit): Stellt die Millisekunden dar, die seit der benutzerdefinierten Discord-Epoche vergangen sind (festgelegt auf den 1. Januar 2015 um 00:00:00 UTC, entsprechend dem Unix-Zeitstempel 1420070400000).
    • 
    
  • Worker-ID (5 Bit): Stellt den internen Server-Worker-Index dar.
    • 
    
  • Prozess-ID (5 Bit): Stellt den internen Prozessindex dar.
    • 
    
  • Inkrement (12 Bit): Ein sequenzieller Zähler, der jede Millisekunde pro Prozess auf 0 zurückgesetzt wird.
    • 




Um lesbare Daten in Discord-Nachrichten anzuzeigen, die sich automatisch an die lokale Zeitzone des anzeigenden Benutzers anpassen, verwenden Entwickler Discord-Zeitstempelgeneratoren. Die Eingabe eines Standard-Unix-Zeitstempels in diese Generatoren erzeugt eine formatierte Markdown-Zeichenfolge. In der folgenden Tabelle sind die verfügbaren Styling-Formate aufgeführt:




       




                    

                        
                            

                                Markdown-Syntax
                                Beispielausgabe (für Unix 1735689600)
                                Beschreibung des Anzeigestils
                            

                        
                        
                            

                                <t:1735689600:t>
                                00:00
                                Kurze Zeit
                            

                            

                                <t:1735689600:T>
                                00:00:00
                                Lange Zeit
                            

                            

                                <t:1735689600:d>
                                01.01.2025
                                Kurzes Date
                            

                            

                                <t:1735689600:D>
                                1. Januar 2025
                                Langes Date
                            

                            

                                <t:1735689600:f>
                                1. Januar 2025 00:00
                                Kurzes Datum/Uhrzeit
                            

                            

                                <t:1735689600:F>
                                Mittwoch, 1. Januar 2025 00:00
                                Langes Datum/Uhrzeit
                            

                            

                                <t:1735689600:R>
                                in 5 Jahren / vor 5 Jahren
                                Relative Zeit
                            

                        
                    

                


Optimierung von Zeitabläufen in verteilten Systemen



Die Verwaltung von Zeitberechnungen in modernen, verteilten Systemen erfordert einen standardisierten Ansatz, um Zeitzonenabweichungen, Fehler bei der Nutzlastgröße und Überlaufabstürze zu verhindern. Die Standardisierung von Datenbankstrukturen auf der Standard-Unix-Epoche vereinfacht Zeitmanipulationsaufgaben und gewährleistet konsistente Abläufe über Microservices und externe Schnittstellen hinweg.




Beachten Sie beim Entwerfen von APIs oder Konfigurieren von Nachrichtenwarteschlangen die folgenden drei Richtlinien:



    
    
  1. Speichern Sie die Zeit im UTC- oder Epochen-Ganzzahlformat: Halten Sie die Persistenzebenen frei von lokalen Zeitzonenversätzen. Wenden Sie Lokalisierungen ausschließlich auf der Präsentationsebene an.
    2. 
    
  2. Priorisieren Sie die 64-Bit-Darstellung: Migrieren Sie beim Entwerfen von Datenbankspalten oder beim Auswählen von Programmierstrukturen von 32-Bit-Typen, um Laufzeitüberläufe für das Jahr 2038 zu verhindern.
    3. 
    
  3. Wählen Sie die richtige Genauigkeit: Passen Sie die Systemspezifikationen an (z. B. verwenden Sie Millisekunden für API-Ereignisse und nur Nanosekunden, wenn Sie verteilte Sperrenerfassungen verfolgen).
    4. 




Bei der Konvertierung von Zeitstempeln oder der Überprüfung von Epochen mithilfe von Browser-Dienstprogrammen stehen Sicherheit und Datenschutz an erster Stelle. Das Konvertierungstool von Toolsaur setzt diese Philosophie direkt um: „Die gesamte Verarbeitung läuft lokal in Ihrem Browser. Ihre Daten werden niemals an unsere Server gesendet.“ Dies garantiert, dass vertrauliche Systemprotokolle, die Datenbankzeitstempel enthalten, niemals an Endpunkte Dritter gelangen.



Häufig gestellte Fragen zu Epochenkonvertern


Warum sind Unix-Zeitstempel zeitzonenunabhängig?



Unix-Zeitstempel stellen die absolut verstrichene Zeit seit einem einzelnen globalen Referenzpunkt (1. Januar 1970, 00:00:00 UTC) dar. Da dieser Referenzstartpunkt unabhängig vom geografischen Standort identisch ist, bleibt die berechnete Ganzzahl des Zeitstempels gleich. Die lokale Zeitzonenanpassung wird nur angewendet, wenn der Zeitstempel innerhalb von Clientschnittstellen in eine für Menschen lesbare Datumszeichenfolge formatiert wird.



Was ist der Unterschied zwischen einem 10-stelligen und einem 13-stelligen Zeitstempel?



Ein 10-stelliger Zeitstempel stellt die Genauigkeit in Sekunden dar (z. B. 1735689600), was typisch für POSIX-Betriebssysteme, Python und SQL-Datenbanken ist. Ein 13-stelliger Zeitstempel stellt die Genauigkeit in Millisekunden dar (z. B. 1735689600000), was für JavaScript-Laufzeiten, Java und moderne REST-APIs Standard ist. Um zwischen ihnen zu wechseln, muss man mit 1.000 multiplizieren oder dividieren.



Wie wird sich das Jahr-2038-Problem auf moderne Datenbanken auswirken?



Wenn eine Datenbankspalte Unix-Zeitstempel mit einem vorzeichenbehafteten 32-Bit-Integer-Datentyp speichert (z. B. INT in älteren Datenbankschemata), führt jeder Datensatz mit einem Zeitstempel nach dem 19. Januar 2038, 03:14:07 UTC, zu einem Überlauf. Dadurch wird die Zahl in einen negativen Wert umgewandelt und zukünftige Daten als 13. Dezember 1901 interpretiert. Systeme müssen diese Spalten in vorzeichenbehaftete 64-Bit-Ganzzahlen (BIGINT) migrieren.



Wie geht die Unix-Zeit mit Schaltsekunden um?



Die Unix-Zeit berücksichtigt keine Schaltsekunden und geht davon aus, dass jeder Tag genau 86.400 Sekunden hat. Wenn eine Schaltsekunde auftritt, wird der Unix-Zeitstempel für eine Sekunde wiederholt oder angehalten. Diese Entwurfswahl vereinfacht die Berechnungsberechnung, führt jedoch zu geringfügigen Abweichungen von den exakten Zeitlinien der koordinierten Weltzeit (UTC).



Was ist eine Discord-Snowflake-ID und wie unterscheidet sie sich von einem Standard-Unix-Zeitstempel?



Eine Discord-Snowflake-ID ist eine benutzerdefinierte 64-Bit-Ganzzahl ohne Vorzeichen, die einen Erstellungszeitstempel zusammen mit Metadaten der Serverarchitektur (Worker-ID, Prozess-ID und ein lokales Inkrement) codiert. Im Gegensatz zu einem standardmäßigen 10-stelligen Unix-Zeitstempel in Sekunden verwendet eine Snowflake-ID eine benutzerdefinierte Epoche, die am 1. Januar 2015 beginnt, und verfolgt Intervalle in Millisekunden, wobei diese hochpräzise Zeit in den ersten 42 Bits der ID gespeichert wird.



Wie können Sie einen Epochenzeitstempel in Microsoft Excel konvertieren?



Excel verfolgt Datumsangaben als Anzahl der seit dem 1. Januar 1900 verstrichenen Tage. Um einen standardmäßigen 10-stelligen Unix-Zeitstempel (Sekunden) in Zelle A1 in ein lesbares Datum in Excel umzuwandeln, wenden Sie die Formel =(A1 / 86400) + 25569 an, wobei 86400 die Anzahl der Sekunden an einem Tag und 25569 der Versatz in Tagen zwischen der Excel-Epoche und der Unix-Epoche ist. Stellen Sie die Zellenformatierung auf „Datum“ oder „Uhrzeit“ ein, um die Ausgabe anzuzeigen.