java13位时间戳转换成时间，先分清秒与毫秒
接口返回一串13位数字，比如1700000000000，直接看根本不知道是哪天。这类值通常是Java里System.currentTimeMillis()或Date.getTime()得到的毫秒时间戳。本文从识别位数开始，带你把它还原成可读的日期时间，并处理时区、负值和常见误判。
在线工具时间戳转换
先确认手里是不是13位毫秒值
13位时间戳指的是从1970年1月1日UTC零点起算的毫秒数。Java的System.currentTimeMillis()、new Date().getTime()、Instant.now().toEpochMilli()返回的都是这个量级。拿到数字先数位数：10位一般是秒，13位才是毫秒。如果误把13位当秒处理，结果会跑到很远的未来；反过来把10位当毫秒，又会落回1970年前后。
一个便于对照的例子：输入13，工具给出的毫秒值是13000，对应1970-01-01T00:00:13.000Z，UTC显示为1970-01-01 00:00:13。这说明13位数值在换算时先被当作毫秒，再折算成秒级时间点。理解这一点，后面看任何长数字都不会慌。
用在线工具走一遍换算
不想写代码时，最快的路径是把数字粘进转换工具。打开时间戳转换，把13位数字填进输入框，选择按毫秒解析，页面会同时给出秒级unix值、毫秒值、ISO格式和UTC格式四种结果。核对时重点看ISO那一行，它带时区标记Z，表示UTC时间，不会因为本地时区不同而漂移。
如果结果明显不对，先检查是否选错了单位。工具默认按输入长度判断，但手工粘贴时偶尔会带上空格或换行，导致位数判断偏差，清理后再试一次即可。需要对照其他位数的换算结果时，可以参考13位时间戳转换成时间的结果与步骤，里面把步骤拆得比较细。
在Java代码里完成转换
代码路径适合需要把转换逻辑嵌进服务的场景。最直接的写法是用Instant.ofEpochMilli(毫秒值)得到Instant，再配合ZoneId.of("Asia/Shanghai")转成ZonedDateTime，最后用DateTimeFormatter格式化成字符串。这样输出的时间自带时区信息，不会出现服务器和本地看到两个结果的情况。
老项目里常见new Date(毫秒值)加SimpleDateFormat的组合，能用，但SimpleDateFormat不是线程安全的，放在静态字段里被多线程共用会出问题。要么每次方法内新建实例，要么换成DateTimeFormatter。另外注意SimpleDateFormat默认使用JVM时区，部署到不同区域的机器上结果可能不一致，显式设置时区更稳妥。
时区、负值和边界情况
时间戳本身是UTC基准，显示成什么时间取决于时区。同一个毫秒值，在东八区和UTC下格式化出来的小时数不同，这不是转换错误。排查时先确认输出用的是哪个时区，再判断对错。
负值也值得留意。证据里输入-3587，得到1969-12-31T23:00:13.000Z；输入-647，得到1969-12-31T23:49:13.000Z。负毫秒表示1970年之前的时间点，Java的Instant和Date都能正常处理，但部分前端库或数据库字段对负值支持不佳，入库前要确认字段类型。
还有一种边界是数值刚好落在整秒附近。输入12、13、14分别对应1970-01-01T00:00:12.000Z、1970-01-01T00:00:13.000Z、1970-01-01T00:00:14.000Z，秒级展示时相邻毫秒值可能看起来一样，比较时要精确到毫秒。
把结果写回业务时的检查清单
转换完成不等于结束。写入数据库前确认字段是bigint或timestamp，前者存毫秒原值，后者由数据库做时区转换，两种策略不要混用。接口返回给前端时，统一用ISO字符串或毫秒数其中一种，避免同一字段两种格式并存。
日志里打印时间戳时，顺手附上格式化后的时间，排查问题能省不少来回。若数据来自其他语言或框架，位数习惯可能不同，比如某些场景会拿到秒级值，这时先判断长度再决定乘不乘1000，不要凭感觉统一处理。
总结
先确认数字是13位毫秒值，再用在线工具或Java的Instant加时区完成换算，最后核对时区设置、负值支持和存储字段类型，避免同一时间在不同环节显示不一致。
相关文章
- jq13位时间戳转换成日期：参数结果核对
说明参数13按Unix秒转换后的UTC日期，并区分数值13与13位毫秒时间戳。
- jq12位时间戳转换成日期：12 对应哪一刻？
参数 12 按 Unix 时间戳换算，对应 1970-01-01 00:00:12（UTC），毫秒数为 12000。本文说明结果含义、换算步骤与相邻参数对照。
- jdk8将时间戳转换成instant：8秒的转换结果
在JDK8中把时间戳8转换为Instant，结果是1970-01-01T00:00:08Z，对应UTC时间00:00:08，毫秒值8000。
- java时间戳转换日期格式14位：先分清秒与毫秒
从14位时间戳的位数困惑讲起，用实例说明秒与毫秒的差别，并给出Java格式化日期与排查错误的做法。
- java时间戳转换成时间6：从参数6看懂秒级换算
以参数6为例，讲清Java时间戳换算成时间的思路：秒与毫秒的区别、UTC与本地时区、边界值与常见报错排查。
常见问题
Q113位时间戳和10位时间戳有什么区别？
13位是毫秒级，10位是秒级，两者相差1000倍。Java默认的currentTimeMillis返回13位；部分语言或接口返回秒。换算前先数位数，选错单位结果会偏差很大。
Q2转换结果比预期早了8小时怎么办？
多半是时区没设对。时间戳基于UTC，格式化时如果用了UTC而你以为在看本地时间，就会差出时区偏移。显式指定ZoneId后再格式化，或统一用ISO字符串展示。
Q3负的13位时间戳能正常转换吗？
可以。负毫秒表示1970年之前的时间点，Java的Instant和Date都支持。要注意目标存储字段和前端展示库是否支持负值，避免在某一环被截断。
Q4为什么相邻的毫秒值显示成同一秒？
秒级展示会丢掉毫秒部分，12、13、14这三个值在只显示到秒时看起来接近。需要区分时保留毫秒位，或比较原始数值而不是格式化后的字符串。