2014-06-13 45 views

回答

2

這裏我假設一個半開的時間間隔,意思是包括開始但不包括結束。首先,我使用LocalDate這一類型來排除牆上時間對日期差異的影響。

public int getCountOfMidnights(Interval interval) { 
    LocalDate start = interval.getStart().toLocalDate(); 
    LocalDate end = interval.getEnd().toLocalDate(); 
    int countOfMidnights = Days.daysBetween(start, end).getDays(); 

    if (interval.getStart().toLocalTime().equals(LocalTime.MIDNIGHT)) { 
    countOfMidnights++; 
    } 

    return countOfMidnights; 
} 

,因爲有機磷農藥自己的答案的UPDATE:

我已經測試他的代碼,尤其是對於引種夏季在二○一三年十月二十○日在午夜跳躍到T01時區「美洲/聖保羅」:00代替。

輸出使用@GabrielBauman產量的溶液:

DateTimeZone tz = DateTimeZone.forID("America/Sao_Paulo"); 
    DateTime start = new DateTime(2013, 10, 20, 5, 0, tz); 
    DateTime end = new DateTime(2013, 10, 21, 0, 0, tz); 
    Interval interval = new Interval(start.withTimeAtStartOfDay(), end); 
    System.out.println(getCountOfMidnights(interval)); // 0!!! 

用我的溶液中的正確結果爲1,還設有在帳戶不採取條件的另一問題,如果一個間隔開始於午夜(OP具有考慮這是否應該算在內。在我看來,是的,另請參見我的評論)。

結論:我們在計算午夜時基本上只有一個約會場景。

因此明智的做法是避免時間類型,其包括在內部的時區(如果可能的話)(如Joda- DateTime或JDK-的GregorianCalendar或ZonedDateTime在新的JSR-310),因爲這裏的時間算術不明確的sooo(它是對於牆壁時間比較也是合情合理的)。這是我使用LocalDate這類本地類型的主要原因。這也是我爲什麼在自己的庫中放棄這種混合類型的幾個原因之一(另一個原因是例如直接存儲在數據庫中的缺失選項)。這些具有日期,時間和時區的多用途類型遠不如大多數用戶所認爲的那樣有用。在大多數情況下,使用本地類型並使用全局類型主要用於時區感知轉換目的。

+0

感謝您的支持。謹慎批評其他答案? –

+0

@GabrielBauman也許你更喜歡你的解決方案,因爲它是一個單線程。但考慮間隔'新的時間間隔(0,86402000,DateTimeZone.UTC)',這將在我的解決方案中產生2天,而在您的解決方案中會產生1天。所以這兩個答案都不相同。 –

+0

感謝您進一步檢查!這裏有一些非常好的信息。我會標記你的答案是正確的;真的很感謝你的努力。 –

0

我想出了以下內容:

public int getCountOfMidnights(Interval i) { 
    return Days.daysIn(i.withStart(i.getStart().withTimeAtStartOfDay())).getDays(); 
} 

從本質上講,我調整間隔的開始時間到時間在一天(通常是午夜)開始,然後計算包含在調整區間充分的天數。

不確定這是比其他答案更好還是更差,等待一些測試,所以我會留在這裏以防萬一有人發表評論。