Java中Date与Timestamp这两种类型的转换方法及关键技术点

Java里Date和Timestamp经常出现在业务代码和数据库交互中，很多人以为两者随便转就行，实际踩坑多集中在毫秒丢失、时区偏移和JDBC时区配置上。java.util.Date表示一个绝对时间戳，内部就是一个从1970年1月1日00:00:00 GMT开始的毫秒数，不带时区信息。java.sql.Timestamp继承自Date，额外增加了纳秒精度，主要用于和数据库的DATETIME、TIMESTAMP字段对应。理解这个继承关系，是掌握两者转换的前提。

一、Date转Timestamp的常用方法

最直接的方式是用Timestamp的构造方法，传入Date的毫秒值，写法是new Timestamp(date.getTime())，简单可靠，适合绝大多数场景。

也可以用valueOf，但要注意它接收的是符合yyyy-MM-dd HH:mm:ss.fffffffff格式的字符串，不是Date对象，传错容易抛IllegalArgumentException。

如果Date本身可能为null，转换前必须判空，否则调用getTime会直接抛空指针，建议在工具方法里统一处理，返回null或默认值。

转换后如果数据库字段精度低于纳秒，多余部分会被截断或四舍五入，取决于数据库实现，不要指望存进去还能拿回完整纳秒。

二、Timestamp转Date的常用方法

因为Timestamp是Date的子类，可以直接向上转型赋值给Date，语法上没问题，但要注意这个Date实际还是Timestamp对象，某些序列化框架可能按子类处理，输出结果和预期不一致。

更稳妥的做法是新建一个Date，传入timestamp.getTime()，得到纯粹的Date对象，避免后续代码误用getNanos。

如果只需要日期部分，可以配合SimpleDateFormat格式化成字符串再解析，但SimpleDateFormat不是线程安全的，多线程共享会解析出错，应每次新建，或者改用线程安全的DateTimeFormatter。

从数据库读出的Timestamp如果为null，同样要判空，很多ORM映射字段没做处理，直接调用方法就会报错。

三、关键技术点与常见坑

时区问题是最大坑。Date存的是绝对时间，但格式化输出依赖默认时区，服务器时区和数据库时区不一致时，看起来就会差几个小时。建议统一使用UTC存储，展示时再转本地时区，同时检查JDBC连接参数里的serverTimezone配置，MySQL尤其常见。

精度差异要提前考虑。Date只到毫秒，Timestamp能到纳秒，Date转Timestamp不会凭空产生纳秒，Timestamp转Date会丢掉纳秒部分，涉及高精度排序、幂等判断时容易出问题。

数据库字段类型影响行为。MySQL的TIMESTAMP会受时区转换影响，并且有范围限制，通常到2038年，DATETIME不做时区转换，存什么读什么，选型时要根据业务确认。

强烈建议新项目迁移到java.time包。用Instant表示绝对时间，LocalDateTime表示不带时区的本地时间，ZonedDateTime带时区，通过Instant.ofEpochMilli和toEpochMilli与毫秒互转，用LocalDateTime和ZoneId转换时区，比Date和Calendar清晰很多。

ORM框架配置也要留意。JPA和MyBatis对Timestamp的映射默认依赖驱动和时区设置，出现入库时间和查询时间不一致，先排查数据库时区、连接参数和JVM默认时区，而不是急着改代码做加减小时。

Date和Timestamp的转换本身很简单，核心写法就是new Timestamp(date.getTime())和new Date(timestamp.getTime())，真正容易出问题的是毫秒与纳秒的精度差异、时区不一致以及null处理。Date代表绝对时间，Timestamp在此基础上扩展了纳秒精度并服务于数据库交互，向上转型虽然可行但可能带来序列化和语义上的隐患。生产环境建议统一时区策略，明确数据库字段类型，检查JDBC的serverTimezone配置，并尽量使用java.time替代旧的日期API，从根源上减少时区和线程安全带来的问题。如果项目还在大量使用SimpleDateFormat，优先替换成DateTimeFormatter，能避免很多隐蔽的线上故障。

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com