本文详解如何修复日期比较逻辑错误，通过统一时间戳单位（毫秒）实现准确筛选最近7天内完成的书籍列表。
本文详解如何修复日期比较逻辑错误，通过统一时间戳单位（毫秒）实现准确筛选最近7天内完成的书籍列表。
在 Android 开发中，使用时间戳（long 类型）比较日期是常见做法，但极易因时间单位不一致导致逻辑失效——这正是您遇到问题的根本原因。
从您的日志可见：
- End Date: 1684159940（仅10位数字）→ 这是 秒级 Unix 时间戳（例如 2023-05-15 10:12:20 对应秒数）
- One Week Ago Millis: 1683740684856（13位数字）→ 这是 毫秒级时间戳（System.currentTimeMillis() 返回值）
二者相差1000倍，因此 endDateMillis >= oneWeekAgoMillis 永远为 false，导致 if 分支永不执行，lastWeekList 始终为空。
✅ 正确做法：将书籍的 endDate（秒级）转换为毫秒级，再参与比较：
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) {
// 关键修复：将秒级 endDate 转为毫秒级（×1000）
long endDateMillis = book.endDate * 1000L;
if (endDateMillis >= oneWeekAgoMillis && endDateMillis <= currentTimeMillis) {
lastWeekList.add(book);
}
}
finishedBooksAdapter.setLastWeekFilter(lastWeekList);
}⚠️ 注意事项：
- 一致性优先：确保所有时间戳使用相同单位（推荐全程使用毫秒），避免混合 seconds 与 milliseconds；
- 存储建议：若可修改数据模型，建议将 FinishedBooks.endDate 直接定义为 long 毫秒值（如 System.currentTimeMillis()），从源头规避单位转换；
- 时区安全：上述逻辑基于系统本地时间，如需跨时区精确处理（如服务端返回 UTC 时间），应结合 TimeZone 或 Instant/LocalDateTime 进行标准化；
- 边界校验：endDateMillis <= currentTimeMillis 可防止未来时间数据干扰，但若业务允许“计划完成时间”，可根据需求调整。
? 小技巧：可通过 new Date(book.endDate * 1000L) 快速验证转换后时间是否合理，辅助调试。
修复后，您的筛选功能将精准返回过去7×24小时内完成的书籍，列表不再为空。
