嘿，这个问题我之前在帮用户排查设备时间异常的时候碰到过类似案例，咱们结合你给出的信息来拆解可能的原因：

最可能的原因：设备系统时间异常 #

你给出的时间戳77204164、77204290，其实就是1970-01-01 21:26:44.164和1970-01-01 21:26:44.290的毫秒级时间戳——这完全符合系统时间被重置到UNIX纪元初始阶段的特征。既然你已经排除了代码转换错误，那问题肯定出在设备的时间源本身，而非App逻辑。具体可能的场景包括：

• 系统时间被手动/第三方App篡改：用户可能误操作修改了系统时间，或者某些拥有高权限的App（比如root后的调试工具、恶意应用）强制把时间改成了1970年附近；部分定制ROM的时间设置界面也可能存在bug，导致时间意外重置。
• RTC硬件故障：设备的实时时钟（RTC）模块负责在关机或休眠时维持时间，如果RTC电池耗尽、模块损坏，设备重启后会默认回到UNIX纪元初始时间（1970-01-01），而且运行过程中也可能出现时钟跳变的情况——这种问题在老旧设备上尤为常见。
• 自动时间同步失效：设备的“自动同步时间”功能被关闭，或者因网络问题（比如长期断网、无法连接NTP服务器）无法同步正确时间，加上之前的时间被意外重置，就会一直停留在1970年的状态。

其他低概率但值得排查的点 #

• 应用权限限制：虽然获取系统时间通常不需要特殊权限，但部分极端定制ROM可能存在权限限制，导致App无法读取正确的系统时间，只能获取到默认的初始时间戳。不过这种情况非常少见，且一般会伴随其他权限相关的异常。
• 设备恢复/工厂模式残留：如果这台设备近期进入过恢复模式、工厂模式，或者执行过系统重置，可能没有完成时间同步的步骤，导致时间停留在初始值。

快速排查步骤 #

1. 直接检查这台设备的系统时间显示，确认是否确实是1970年左右的时间；
2. 开启设备的“自动同步时间”功能，连接稳定网络后等待几分钟，看时间是否恢复正常；
3. 查看设备上是否安装了可能修改系统时间的工具类App，尤其是root权限下的应用；
4. 如果是老旧设备，可以联系厂商或维修人员检查RTC模块的状态；
5. 临时在App中添加日志，打印获取时间戳时的完整Date对象，确认App读取到的原始时间就是异常的1970年时间——这能彻底排除写入/上传环节的问题。

内容的提问来源于stack exchange，提问作者Alex Gimondi