本文详解 Android 开发中因时间戳单位不一致（秒 vs 毫秒）导致的日期筛选失效问题，并提供健壮、可复用的 lastWeekFilter 实现方案。
本文详解 android 开发中因时间戳单位不一致（秒 vs 毫秒）导致的日期筛选失效问题，并提供健壮、可复用的 `lastweekfilter` 实现方案。
在实际开发中，你可能遇到这样的场景：用户录入书籍完成时间（如 1684159940），后端或本地存储常以秒级 Unix 时间戳保存；而 Java/Android 的 System.currentTimeMillis() 返回的是毫秒级时间戳。两者单位不一致，直接比较会导致逻辑永远失败——正如你的日志所示：
End Date: 1684159940 ← 单位：秒（约 2023-05-15） One Week Ago Millis: 1683740684856 ← 单位：毫秒（约 2023-05-08）
1684159940 远小于 1683740684856，因此 if (endDateMillis >= oneWeekAgoMillis) 永远为 false，列表始终为空。
✅ 正确做法：统一时间单位为毫秒
你需要将 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;
for (FinishedBooks book : finishedBooks) {
// 关键修复：将秒级时间戳转为毫秒
long endDateMillis = book.endDate * 1000L;
if (endDateMillis >= oneWeekAgoMillis && endDateMillis <= currentTimeMillis) {
lastWeekList.add(book);
}
}
finishedBooksAdapter.setLastWeekFilter(lastWeekList);
}⚠️ 注意事项与增强建议
-
空值防护：确保 book.endDate 不为 0 或负数，避免无效时间干扰筛选：
if (book.endDate <= 0) continue;
-
时区一致性：若 endDate 来自服务端且含时区信息（如 ISO 8601 字符串），建议改用 java.time API（Android API ≥ 26，或使用 ThreeTenABP 库）进行更可靠的解析与比较：
// 示例：使用 LocalDate/Instant（推荐长期维护项目） Instant now = Instant.now(); Instant oneWeekAgo = now.minus(7, ChronoUnit.DAYS); Instant bookInstant = Instant.ofEpochSecond(book.endDate); // 秒级 → Instant if (!bookInstant.isBefore(oneWeekAgo) && !bookInstant.isAfter(now)) { lastWeekList.add(book); } -
性能优化：对大数据量列表，可考虑使用 Java 8 Stream 提升可读性（非必须，但更函数式）：
List<FinishedBooks> lastWeekList = finishedBooks.stream() .filter(book -> { long ms = book.endDate * 1000L; return ms >= oneWeekAgoMillis && ms <= currentTimeMillis; }) .collect(Collectors.toList());
✅ 总结
根本原因不是逻辑错误，而是时间单位混淆：秒级时间戳未转换即与毫秒级时间比较。只需一行修正 book.endDate * 1000L，即可让筛选逻辑准确生效。后续建议逐步迁移到 java.time API，提升代码健壮性与可维护性。
