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.

滑动时间轴可直观对比多个时区与 UTC/本地时间。

-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 的本地解释：




    

        
            

                时区区域
                本地化日期和时间
                偏移值
            

        
        
            

                格林尼治标准时间 / 世界标准时间
                2020 年 1 月 2 日星期四 00:00:00
                世界标准时间+00:00
            

            

                印度（加尔各答）
                2020 年 1 月 2 日星期四 05:30:00
                世界标准时间+05:30
            

            

                美国（纽约）
                2020 年 1 月 1 日星期三 19:00: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 索引。



秒与毫秒：导航数字精度



现代软件中的时间戳根据应用程序的要求以不同的精度级别运行。大多数系统设计都采用以下四种分辨率之一：



    
    
  1. 秒（10 位数字格式）： 例如，1735689600。这是 Python、PHP、关系数据库（如 PostgreSQL 和 MySQL）和 Linux shell 环境使用的标准解析。
    2. 
    
  2. 毫秒（13 位格式）： 例如，1735689600000。这种格式是 JavaScript、Java 和大多数基于 JSON 的现代 Web API 的标准格式。
    3. 
    
  3. 微秒（16 位格式）： 例如，1735689600000000。通常保留用于高精度跟踪、系统日志记录和低级诊断平台。
    4. 
    
  4. 纳秒（19 位格式）： 用于专门的内核级跟踪系统和实时处理网络。
    5. 




要将秒转换为毫秒，请将整数值乘以 1,000。相反，要将毫秒转换回标准秒，请应用整数除以 1,000 以去除尾随数字。




了解里程碑和连续的 Unix 时间戳可以为时间顺序和规模提供清晰的视角：




__代码_0__ __代码_1__ __代码_2__ __代码_3__ __代码_4__ __代码_5__




    

        
            

                Unix时间戳
                等效 UTC 日期和时间
                里程碑背景
            

        
        
            

                0
                世界标准时间 1970 年 1 月 1 日星期四 00:00:00
                Unix时代
            

            

                1,000,000,000
                世界标准时间 2001 年 9 月 9 日星期日 01:46:40
                十亿分之一第二个里程碑
            

            

                1,234,567,890
                世界标准时间 2009 年 2 月 13 日星期五 23:31:30
                连续的十进制数字进展
            

            

                1,735,689,600
                世界标准时间 2025 年 1 月 1 日星期三 00:00:00
                2025 年伊始
            

            

                2,000,000,000
                世界标准时间 2033 年 5 月 18 日星期二 03:33:20
                二十亿第二个里程碑
            

            

                2,147,483,647
                世界标准时间 2038 年 1 月 19 日星期二 03:14:07
                绝对最大有符号 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 作为参考）转换回本地时间的方法。




                                             __代码_29__  __代码_30__ __代码_31__  __代码_32__




    

        
            

                语言/平台
                当前纪元（秒）
                将纪元转换为日期
            

        
        
            

                JavaScript
                Math.floor(Date.now() / 1000)
                新日期(1800000000 * 1000).toLocaleString()
            

            

                Python
                int(时间.时间())
                时间.ctime(1800000000)
            

            

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

            

                去
                time.Now().Unix()
                时间.Unix(1800000000, 0)
            

            

                PHP
                时间（）
                日期('r', 1800000000)
            

            

                红宝石
                时间.now.to_i
                时间.at(1800000000)
            

            

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

            

                C++
                uration_cast<秒>(system_clock::now().time_since_epoch()).count()
                —
            

            

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

            

                珀尔
                时间
                标量当地时间(1800000000)
            

            

                PostgreSQL
                选择提取（EPOCH FROM now（））；
                选择 TO_TIMESTAMP(1800000000);
            

            

                MySQL
                选择 UNIX_TIMESTAMP(NOW());
                选择 FROM_UNIXTIME(1800000000);
            

            

                SQL服务器
                选择 DATEDIFF(SECOND, '1970-01-01', GETUTCDATE());
                选择 DATEADD(SECOND, 1800000000, '1970-01-01');
            

            

                SQLite
                选择 unixepoch();
                选择日期时间（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 日期时间刻度： 从公历第一年开始以 100 纳秒块计数。
    • 
    
  • Chrome/WebKit 时间戳： 从 1601 年 1 月 1 日开始以微秒为单位计数。
    • 
    
  • Mac HFS+： 从 1904 年 1 月 1 日开始以秒为单位计算。
    • 
    
  • NTP 时间戳： 从 1900 年 1 月 1 日开始以秒为单位计算。
    • 
    
  • GPS 时间： 从 1980 年 1 月 6 日开始以秒和周计算。
    • 
    
  • SAS 时间戳： 从 1960 年 1 月 1 日开始以秒或天计算。
    • 
    
  • 可可核心数据： 从 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 的结构分为四个不同的组成部分：



    
    
  • 时间戳（42 位）： 表示自自定义 Discord 纪元（设置为 2015 年 1 月 1 日 00:00:00 UTC，相当于 Unix 时间戳 1420070400000）以来经过的毫秒数。
    • 
    
  • Worker ID（5位）：表示内部服务器worker索引。
    • 
    
  • 进程ID（5位）：表示内部进程索引。
    • 
    
  • 增量（12 位）： 每个进程每毫秒重置为 0 的顺序计数器。
    • 




为了在 Discord 消息中显示可读日期并自动调整为查看用户的本地时区，开发人员使用 Discord 时间戳生成器。将标准 Unix 时间戳输入到这些生成器中会生成格式化的 Markdown 字符串。下表列出了可用的样式格式：




__代码_0__ __代码_1__ __代码_2__ __代码_3__ __代码_4__ __代码_5__ __代码_6__ __代码_7__




                    

                        
                            

                                Markdown 语法
                                示例输出（对于 Unix 1735689600）
                                显示样式说明
                            

                        
                        
                            

                                <t:1735689600:t>
                                00:00
                                短时间
                            

                            

                                <t:1735689600:T>
                                00:00:00
                                很久
                            

                            

                                <t:1735689600:d>
                                01/01/2025
                                短日期
                            

                            

                                <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 或配置消息队列时，请记住以下三个准则：



    
    
  1. 以 UTC 或纪元整数格式存储时间： 保持持久层不含本地时区偏移。仅在表示层应用本地化。
    2. 
    
  2. 优先考虑 64 位表示： 在设计数据库列或选择编程结构时，请远离 32 位类型以防止 2038 年运行时溢出。
    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 时间戳会重复或暂停一秒。这种设计选择简化了计算数学，但会导致与精确的协调世界时 (UTC) 时间线略有偏差。



什么是 Discord 雪花 ID 以及它与标准 Unix 时间戳有何不同？



Discord 雪花 ID 是一个自定义 64 位无符号整数，它对创建时间戳以及服务器架构元数据（工作进程 ID、进程 ID 和本地增量）进行编码。与以秒为单位的标准 10 位 Unix 时间戳不同，雪花 ID 使用从 2015 年 1 月 1 日开始的自定义纪元，并以毫秒为单位跟踪间隔，并将此高精度时间存储在 ID 的前 42 位中。



如何在 Microsoft Excel 中转换纪元时间戳？



Excel 将日期跟踪为自 1900 年 1 月 1 日以来经过的天数。要将单元格 A1 中的标准 10 位 Unix 时间戳（秒）转换为 Excel 中的可读日期，请应用公式 =(A1 / 86400) + 25569，其中 86400 是一天中的秒数，25569 是 Excel 纪元与 Unix 纪元之间的天数偏移量。将单元格格式设置为“日期”或“时间”以查看输出。