currentTimeMillis 4小時

我有一個簡單的問題，我有以下功能，並有它的參數，叫cacheTime，我應該如何設置它爲4小時，我應該將它設置爲4 * 3600000？currentTimeMillis 4小時

public static File getCache(String name, Context c, int cacheTime) 
{ 
    if (cacheTime <= 0) 
     return null; 
    File cache = new File(c.getCacheDir(), name); 
    long now = System.currentTimeMillis(); 
    if (cache.exists() && (now - cache.lastModified() < cacheTime)) 
     return cache; 
    return null; 
}

來源

2013-02-15 NullPointer

4 * 3600000.這是毫秒，而不是秒。 – 323go 2013-02-15 21:47:52

@ 323go謝謝，編輯。 – NullPointer 2013-02-18 15:46:21

毫秒是1/1000秒。所以4小時將是4 * 60 * 60 * 1000 = 14,400,000

對於緩存失效，這可能是好的。也就是說，日期數學通常是危險的。在處理大於毫秒的時間單位時，可以輕鬆地在夏令時轉換，閏秒以及Calendar要處理的所有其他事情中絆倒。在某些情況下，這種罕見的不準確性是可以接受的，而在其他情況下則不然。在做數學計算時要小心。

要確定較大單位時間（如+1天）中的人體消耗時間，請使用Calendar.roll（）。

來源

2013-02-15 21:50:53 Gus

我會爭辯* *與*相反是真實的。四個小時是四個小時。如果某些時區決定使用GMT *的本地表示形式......如果使用毫秒，則四小時仍爲四小時。當你依賴當地時間時，你通常會遇到問題。 – 2013-02-15 22:02:49

這很好，可能不一定是問題。在夏令時轉換，閏秒或系統時鐘更改以外的任何其他情況下，如果您真的只需要「從現在開始x小時」，它不會失敗。一小時是一小時，毫秒是毫秒。雖然你提到的問題是常見的與日期有關的問題，但當你嚴格地處理持續時間的差異時（而不是像「明天在同一時間」），它將工作得很好。 – kabuko 2013-02-15 22:03:51

@kabuko這是一個很好的觀點，我認爲對於緩存失效，結果永遠不會顯示給用戶，因此可能無法看到結果。在展示案例中，如果仔細地通過具有適當時區的DateFormat運行數學結果，您可能很安全。當我看到人們在做與日期/時間有關的數學時，我只是很癢...... – Gus 2013-02-15 22:15:01

4 * 1000 * 3600

有在第二1000毫秒，在一個小時3600秒。

來源

2013-02-15 21:48:02 ty733420

// 4 hours * 60 (min/hour) * 60 (sec/min) * 1000 (msec/sec) 
getCache(name, c, 4 * 3600 * 1000);

來源

2013-02-15 21:48:12 corvec

我會建議將這些評論收集到代碼上面的一條評論中。它會更可讀。 – Gus 2013-02-15 21:53:21

正式注意並更新。 – corvec 2013-02-15 22:12:29

學習使用得心應手TimeUnit枚舉，所以你可以做的事情，像這樣：

TimeUnit.Hours.toMillis(4)

而且不依賴於餐巾紙數學和幻數都在你的代碼。

來源

2013-02-15 21:51:51 Hiro2k

不幸的是，TimeUnit的javadoc並不清楚實際結果是什麼，而4也是一個神奇的數字。然而這可讀性更強。 – Gus 2013-02-15 21:56:52

其實4可以是可配置的，可以從外部屬性讀入或作爲參數傳入。你說得對javadoc不太清楚，但讀取它是這樣的：轉換4小時到毫秒。 – Hiro2k 2013-02-15 21:59:40

currentTimeMillis 4小時

回答

相關問題