Unix时间戳与日期时间的双向转换 · 支持秒级和毫秒级 · 多种日期格式输出
各语言获取和转换时间戳的代码片段
// 获取当前时间戳（毫秒） const ts = Date.now(); // 获取当前时间戳（秒） const tsSec = Math.floor(Date.now() / 1000); // 时间戳转 Date const date = new Date(ts); // Date 转时间戳（秒） const ts2 = Math.floor(date.getTime() / 1000); // 格式化输出 console.log(date.toISOString()); // 2026-06-07T08:06:31.000Z
// 获取当前时间戳（毫秒）
long ts = System.currentTimeMillis();
// 获取当前时间戳（秒）
long tsSec = ts / 1000;
// 时间戳转 Date
Date date = new Date(ts);
// Date 转时间戳
long ts2 = date.getTime();
// 格式化输出（Java 8+）
import java.time.Instant;
import java.time.format.DateTimeFormatter;
String iso = Instant.ofEpochMilli(ts)
.atZone(java.time.ZoneId.systemDefault())
.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME);
// 2026-06-07T16:06:31import time
from datetime import datetime
# 获取当前时间戳（秒）
ts = int(time.time())
# 获取当前时间戳（毫秒）
ts_ms = int(time.time() * 1000)
# 时间戳转 datetime
dt = datetime.fromtimestamp(ts)
# datetime 转时间戳
ts2 = int(dt.timestamp())
# 格式化输出
print(dt.strftime('%Y-%m-%d %H:%M:%S'))
# 2026-06-07 16:06:31
print(dt.isoformat())
# 2026-06-07T16:06:31// 获取当前时间戳（秒）
long ts = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
// 获取当前时间戳（毫秒）
long tsMs = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
// 时间戳转 DateTime
DateTime dt = DateTimeOffset
.FromUnixTimeSeconds(ts)
.LocalDateTime;
// DateTime 转时间戳
long ts2 = new DateTimeOffset(dt)
.ToUnixTimeSeconds();
// 格式化输出
Console.WriteLine(dt.ToString("yyyy-MM-dd HH:mm:ss"));
// 2026-06-07 16:06:31import (
"fmt"
"time"
)
// 获取当前时间戳（秒）
ts := time.Now().Unix()
// 获取当前时间戳（毫秒）
tsMs := time.Now().UnixMilli()
// 时间戳转 Time
t := time.Unix(ts, 0)
// Time 转时间戳
ts2 := t.Unix()
// 格式化输出
fmt.Println(t.Format("2006-01-02 15:04:05"))
// 2026-06-07 16:06:31
fmt.Println(t.Format(time.RFC3339))
// 2026-06-07T16:06:31+08:00理解Unix时间戳的原理与常见应用场景
Unix时间戳（Unix Timestamp）是一种在世界范围内被广泛使用的时间表示方式，它定义为从1970年1月1日 00:00:00 UTC（即Unix纪元）开始所经过的秒数，不考虑闰秒。这个看似随意的起始日期实际上有着深远的历史原因——1970年前后，AT&T贝尔实验室的Ken Thompson和Dennis Ritchie正在开发Unix操作系统，他们需要一个简单有效的方式来记录文件的时间信息，于是选择了1970年1月1日作为"时间的零点"。自此以后，时间戳便成为了计算机科学中最基础也最重要的时间表示方法之一。今天，几乎所有主流操作系统、数据库、编程语言和网络协议都在使用时间戳——从Linux的文件系统到MySQL的TIMESTAMP类型，从HTTP的Date头到JSON Web Token的exp字段，时间戳无处不在。它的最大优势在于跨时区、跨平台的一致性——无论你在北京还是纽约，同一个时间戳代表的是同一个时刻，不存在"冬令时/夏令时"或"时区转换"的困扰。
秒级时间戳（10位）：以秒为单位的整数，范围通常为10位数字（如 1780819591）。这是Unix时间戳的标准格式，在大多数数据库、API和老旧系统中广泛使用。MySQL的UNIX_TIMESTAMP()函数返回的就是秒级时间戳。毫秒级时间戳（13位）：以毫秒为单位，范围通常为13位数字（如 1780819591000）。毫秒级时间戳提供了更高的精度，在现代系统中越来越普遍——JavaScript的Date.now()、Java的System.currentTimeMillis()以及大多数现代日志系统都使用毫秒级时间戳。在时间戳转换时，如果输入的是一串13位的数字，本工具会自动识别为毫秒级时间戳并正确处理。两者的换算关系非常简单：毫秒级时间戳 = 秒级时间戳 x 1000。
如果你接触计算机比较早，可能听说过著名的"2038年问题"（Year 2038 Problem）。这个问题的根源在于：许多老旧系统使用32位有符号整数（signed int32）来存储秒级时间戳，其最大值为 2^31 - 1 = 2,147,483,647，对应的时间是2038年1月19日 03:14:07 UTC。当时间超过这个节点后，32位整数会"溢出"变成一个负数——时间倒退到了1901年。这类似于2000年的"千年虫"问题，但影响范围更广——因为时间戳深深嵌入了操作系统内核、文件系统、数据库和嵌入式设备（如工业控制器、路由器、早期智能手机）。好消息是：大多数现代系统已经迁移到了64位时间戳（可以支持到约2920亿年后），Java 8+、Python 3、64位Linux等都已经不再受2038年问题的影响。但如果你还在维护老旧的C语言程序或嵌入式设备，2038年问题值得提前关注。
两种最通用的时间表示标准
ISO 8601是由国际标准化组织（ISO）制定的日期和时间表示标准，格式为YYYY-MM-DDTHH:mm:ss.sssZ。它被设计为"人类可读且机器可解析"的通用格式，在全球范围内被广泛采用。ISO 8601的核心优点包括：①排序友好——因为年-月-日的顺序是从大到小排列的，按字母顺序排序就等于按时间顺序排序（这一点YYYY-MM-DD格式尤其方便）；②无歧义——2026-06-07明确表示2026年6月7日，不会被混淆为7月6日（而06/07/2026在不同国家则可能产生歧义）；③时区标识清晰——末尾的Z表示UTC时间，+08:00表示东八区（北京时间），一目了然。ISO 8601是RESTful API中推荐使用的日期格式，也是JavaScript中Date.toISOString()方法的默认输出格式。
RFC 2822（及其前身RFC 822）定义了互联网电子邮件中使用的日期时间格式：Day, DD Mon YYYY HH:MM:SS +TZ（如 Sun, 07 Jun 2026 08:06:31 GMT）。这个格式在HTTP协议响应头（如Last-Modified、Expires）、电子邮件头部（Date字段）以及RSS/Atom订阅源中广泛出现。RFC 2822格式的特点是用三个字母的英文缩写表示星期和月份，并明确标注时区（通常是GMT或+-偏移）。相比ISO 8601，RFC 2822更"口语化"——它更接近人类在日常英语中描述日期的方式（"Sunday, June 7th"），但同时保留了一定的机器解析友好度。在编程中，JavaScript的Date.toUTCString()方法返回的格式与RFC 2822非常接近，而PHP中可以用date('r')来生成完整的RFC 2822格式。
从前端开发到后端日志，时间戳无处不在
①API接口鉴权：大多数开放API（如微信支付、阿里云、AWS）要求请求中携带时间戳参数，用于防止"重放攻击"——服务器验证时间戳与当前时间的偏差是否在允许范围内（通常为5分钟内），超时的请求会被自动拒绝。②数据库时间存储：MySQL的TIMESTAMP类型本质上存储的就是Unix时间戳（范围1970-2038），而DATETIME存储的是字符串表示（范围1000-9999）。在需要跨时区查询和排序的场景中，用整数存储时间戳比用字符串存储日期更高效。③前端实时时钟：本页面顶部的实时时钟就是通过JavaScript的Date.now()获取毫秒时间戳，再用setInterval每秒刷新显示来实现的。④日志与监控：Nginx的access.log、Docker的容器日志、Kubernetes的事件记录，几乎所有的系统日志都以时间戳开头——它让分布在不同时区、不同服务器上的事件能够在统一的时间轴上排序和关联。⑤JWT Token过期控制：JSON Web Token中的exp（expiration）和iat（issued at）字段都是Unix时间戳，用于精确控制Token的有效期。⑥缓存过期策略：Redis的EXPIRE命令、浏览器Cache-Control的max-age、CDN的缓存刷新——底层的过期判断都依赖于时间戳的数值比较。⑦分布式系统中的事件排序：在分布式数据库中（如Cassandra、HBase），时间戳常被用作"冲突解决"的依据——"最后写入者获胜"（Last-Write-Wins）策略就是通过比较时间戳来决定哪个版本的数据是最新的。
关于时间戳转换，您可能想了解的那些事
时间戳本身不包含时区信息——它就是一个从1970年1月1日00:00:00 UTC开始计数的纯数字。无论在哪个时区，同一个时间戳代表的是同一个时刻。时区的转换发生在"时间戳→人类可读日期"的过程中：当你将一个时间戳转换为本地时间时，你的操作系统或浏览器会根据你所在的时区自动进行偏移计算。比如时间戳1780819591在UTC时区对应2026-06-07 08:06:31，在北京时间（UTC+8）则对应2026-06-07 16:06:31。这正是时间戳的优雅之处——用一个简单的数字，统一了地球上所有角落的时间表达。
最常见的原因有四个：①单位混淆——把毫秒级时间戳当成了秒级（13位数字被当成了10位），结果转换出来的日期可能是几万年以后或以前的；或者反过来，把秒级当成了毫秒级，结果转换出来的是1970年1月1日刚过几十分钟。本工具自动检测数字位数（13位=毫秒级，10位=秒级），杜绝了这个困扰。②时区差异——同一个时间戳在不同时区显示的时间不同，如果你比对的是UTC时间和北京时间，会有8小时的差异。③32位系统溢出——如果你在老旧的32位系统上使用time()函数，2038年1月19日之后的时间戳可能溢出为负数。④输入的不是纯数字——时间戳必须是纯数字（整数），如果带了小数点、逗号或字母，转换结果将不可预测。
本工具使用的是浏览器原生的JavaScript Date对象进行时间戳转换，其精度和准确性与操作系统时钟一致。秒级和毫秒级时间戳的关系是1秒 = 1000毫秒——因此如果你看到秒级时间戳是1780819591，对应的毫秒级就是1780819591000。如果你输入的原始时间戳是秒级的，工具会自动在末尾补3个0来生成毫秒级时间戳；反之如果输入的是毫秒级的，工具会去掉末尾3位来生成秒级时间戳。