Java 判斷兩個時間戳是否同一天：毫秒級精確、時區安全實現

比較兩個 long 毫秒時間戳是否屬於同一天，看似簡單卻暗藏時區、夏令時、閏秒陷阱。本文提供生產級實現，對比多種方案優劣，涵蓋 Java 8 LocalDate、手工計算、資料庫層面方案。

核心難點

• 時區差異：同一毫秒值在 UTC+8 是 23:00，UTC-5 可能是前一天 10:00。
• 夏令時切換：某天 23 小時或 25 小時，固定 86400000ms 判斷失效。
• 閏秒：極少見但理論上存在。

方案一：Java 8+ LocalDate (推薦) ⭐⭐⭐⭐⭐

import java.time.Instant;
import java.time.LocalDate;
import java.time.ZoneId;

public class TimeUtil {
    /** 判斷兩個毫秒時間戳在指定時區是否同一天 */
    public static boolean isSameDay(long ms1, long ms2, ZoneId zone) {
        LocalDate d1 = Instant.ofEpochMilli(ms1).atZone(zone).toLocalDate();
        LocalDate d2 = Instant.ofEpochMilli(ms2).atZone(zone).toLocalDate();
        return d1.equals(d2);
    }

    /** 使用系統預設時區 */
    public static boolean isSameDay(long ms1, long ms2) {
        return isSameDay(ms1, ms2, ZoneId.systemDefault());
    }
}

• ✅ 正確處理時區、夏令時、閏年。
• ✅ 程式碼極簡、可讀性強。
• ✅ 可指定業務時區 (如交易系統統一用 UTC)。

方案二：手工計算 (兼容 Java 7/舊系統) ⭐⭐⭐

public class TimeUtilLegacy {
    private static final long MILLIS_PER_DAY = 24 * 60 * 60 * 1000L;

    /** 原始碼邏輯：修正時區偏移後比較「天數」 */
    public static boolean isSameDay(long ms1, long ms2) {
        long interval = ms1 - ms2;
        if (interval >= MILLIS_PER_DAY || interval <= -MILLIS_PER_DAY) {
            return false; // 差距超過一天直接 false
        }
        // 關鍵：加上當時刻的時區偏移量，再除以一天毫秒數得到「天序數」
        long day1 = (ms1 + TimeZone.getDefault().getOffset(ms1)) / MILLIS_PER_DAY;
        long day2 = (ms2 + TimeZone.getDefault().getOffset(ms2)) / MILLIS_PER_DAY;
        return day1 == day2;
    }
}

• ✅ 無第三方依賴，JDK 1.1+ 可用。
• ⚠️ 依賴 TimeZone.getDefault()，JVM 啟動參數 -Duser.timezone 影響結果。
• ⚠️ 夏令時邊界 (如 2023-03-12 2:00 跳至 3:00) 可能產生 23 小時一天，邏輯仍成立因為用偏移量修正。

方案三：Apache Commons Lang DateUtils.isSameDay() ⭐⭐⭐

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.14.0</version>
</dependency>

// 使用
Date date1 = new Date(ms1);
Date date2 = new Date(ms2);
boolean same = DateUtils.isSameDay(date1, date2); // 內部用 Calendar 比較 YEAR/MONTH/DAY_OF_MONTH

• ✅ 專案已引入 commons-lang3 時零成本。
• ⚠️ 底層用 Calendar，效能略低於 LocalDate。

方案四：資料庫層面比較 (SQL)

若時間戳存於資料庫，推薦下推計算：

-- MySQL
SELECT DATE(CONVERT_TZ(FROM_UNIXTIME(ms1/1000), '+00:00', '+08:00')) 
     = DATE(CONVERT_TZ(FROM_UNIXTIME(ms2/1000), '+00:00', '+08:00')) AS same_day;

-- PostgreSQL
SELECT (to_timestamp(ms1/1000) AT TIME ZONE 'UTC+8')::date 
     = (to_timestamp(ms2/1000) AT TIME ZONE 'UTC+8')::date AS same_day;

效能基準測試 (JMH, 1億次調用)

邊界測試案例

@Test
void testBoundaries() {
    ZoneId shanghai = ZoneId.of("Asia/Shanghai");
    // 夏令時不存在於中國，但測試紐約
    ZoneId ny = ZoneId.of("America/New_York");

    // 2024-03-10 夏令時開始：2:00 -> 3:00 (少 1 小時)
    long before = ZonedDateTime.of(2024,3,10,1,30,0,0, ny).toInstant().toEpochMilli(); // 1:30 EST
    long after  = ZonedDateTime.of(2024,3,10,3,30,0,0, ny).toInstant().toEpochMilli(); // 3:30 EDT
    assertTrue(TimeUtil.isSameDay(before, after, ny)); // 同一天

    // 跨天邊界
    long night = ZonedDateTime.of(2024,1,1,23,59,59,999_000_000, shanghai).toInstant().toEpochMilli();
    long morning = ZonedDateTime.of(2024,1,2,0,0,0,0, shanghai).toInstant().toEpochMilli();
    assertFalse(TimeUtil.isSameDay(night, morning, shanghai));
}

最佳實踐總結

1. 新專案：直接用 java.time.LocalDate，指定業務時區。
2. 舊專案 (Java 7/8)：複製 TimeUtilLegacy，單元測試覆蓋夏令時邊界。
3. 高頻熱點路徑：手工計算最快，但需文檔註明假設 (固定時區、無夏令時)。
4. 分散式系統：統一使用 UTC 儲存，比較時顯式傳入 ZoneId.of("UTC")。