本文详解 android 开发中因时间戳精度不一致（秒 vs 毫秒）引发的日期过滤失败问题，通过统一单位、校验逻辑和代码优化，确保“最近一周完成书籍”筛选功能准确生效。
本文详解 android 开发中因时间戳精度不一致（秒 vs 毫秒）引发的日期过滤失败问题，通过统一单位、校验逻辑和代码优化，确保“最近一周完成书籍”筛选功能准确生效。
在 Android 项目中，当需要根据完成时间筛选“最近一周内读完的书籍”时，一个常见却隐蔽的陷阱是：时间戳单位不一致。从你的日志可见关键线索：
I/System.out: End Date: 1684159940 ← 仅10位数字（单位：秒） I/System.out: One Week Ago Millis: 1683740684856 ← 13位数字（单位：毫秒）
book.endDate 存储的是 Unix 秒级时间戳（如 1684159940 表示 2023-05-15 14:12:20），而 System.currentTimeMillis() 返回的是 毫秒级时间戳（如 1683740684856）。直接比较 endDateMillis >= oneWeekAgoMillis 相当于用「秒」和「毫秒」做数值比对——前者比后者小约 1000 倍，自然永远不满足条件。
✅ 正确做法：统一转换为毫秒
只需将 book.endDate 乘以 1000，将其从秒级转为毫秒级，再与系统时间对比：
private void lastWeekFilter(List<finishedbooks> finishedBooks) {
List<finishedbooks> lastWeekList = new ArrayList();
long currentTimeMillis = System.currentTimeMillis();
long oneWeekAgoMillis = currentTimeMillis - 7L * 24L * 60L * 60L * 1000L; // 7天毫秒数
for (FinishedBooks book : finishedBooks) {
// 关键修复：将秒级时间戳转为毫秒
long endDateMillis = book.endDate * 1000L;
// 现在单位一致，比较可靠
if (endDateMillis >= oneWeekAgoMillis && endDateMillis <h3>⚠️ 注意事项与增强建议</h3>
<ul>
<li>
<strong>数据源头校验</strong>：检查 FinishedBooks.endDate 的赋值逻辑。若后端返回的是秒级时间戳（常见于 JSON API），应在保存前统一转为毫秒存入；或在模型层封装 getter（如 getEndDateInMillis()）自动处理转换。</li>
<li>
<strong>时区安全</strong>：System.currentTimeMillis() 基于 UTC，若业务需按本地时区“过去7天”筛选（如用户期望“本周一至今”），应使用 Calendar 或 LocalDateTime + ZoneId 进行更严谨的日期运算。</li>
<li>
<strong>边界情况处理</strong>：当前逻辑包含 currentTimeMillis（即“此刻”），但实际业务中，用户更可能关注“过去7×24小时内的完成记录”。若需严格按日历周（如周一至周日）筛选，建议改用 TemporalAdjusters。</li>
<li>
<strong>性能提示</strong>：对于大量数据，可考虑在数据库查询层直接过滤（如 Room 中使用 @Query + datetime 函数），避免全量加载后遍历。</li>
</ul>
<h3>✅ 总结</h3>
<p>时间戳比较失效的根本原因不是逻辑错误，而是<strong>单位错配</strong>。牢记：<br>
? System.currentTimeMillis() → 毫秒（13位）<br>
? Unix 时间戳（JSON/API 常见）→ 秒（10位）<br><strong>始终确保参与比较的两个时间值单位完全一致</strong>——这是日期过滤类功能稳定运行的第一道防线。</p></finishedbooks></finishedbooks>
