Google Drive SDK getModifiedDate（）與setModifiedDate（）不同

我遇到'Google Drive Web APIs'的'setModifiedDate（）'方法的問題，我不知道它是通過設計還是bug 。Google Drive SDK getModifiedDate（）與setModifiedDate（）不同

當更新使用下面的結構修改日期：

DateTime md = DateTime.parseRfc3339("2014-11-02T12:09:58.000-07:00"); 
    File body = new File().setModifiedDate(md); 
    service.files().patch(id, body).setSetModifiedDate(true).execute();

的日期/時間正確更新。請注意，輸入日期時間變量MD可以顯示爲

2014-11-02T12:09:58.000-07:00, and 
md.getTimeZoneShift() reports -420 minutes

當使用例如這個結構以後讀取該文件的修改日期：

FileList gLst = service.files().list().execute(); 
for (File gFl : gLst.getItems()) 
    md = gFl.getModifiedDate();

日期時間「MD」變量有正確的GMT時間，但時移（UTC偏移）信息丟失。的時間將被報告爲

2014-11-02T19:09:58.000Z and 
md.getTimeZoneShift() reports 0 minutes

這肯定是正確的ZULU（GMT）時間的文件，但它從我的時區修飾的事實（GMT-07：00）都將丟失。我期望得到相同的日期時間格式，即

2014-11-02T12:09:58.000-07:00 
and md.getTimeZoneShift() reports -420 minutes

當我修補。

這是正確的行爲，還是我錯過了什麼？

來源

2014-11-02 seanpj

這可能不是一個錯誤，因爲它被正確轉換，考慮到原始偏移量，並且似乎沒有針對它的特殊處理的額外標誌。

將值存儲在純服務器端作爲計算，所有類型的操作都可以變得更加簡單快捷。方法文檔File.getModifiedDate()也相當基礎，並指出DateTime將被格式化爲RFC 3339時間戳。考慮到這一點，即使您正在交付「正確」的時區，您也不應該依賴它，並且您應該編寫代碼來動態處理時區，以防萬一您突然傳遞了DateTime例如，偏移量爲+08：45。

來源

2014-11-02 20:15:14

謝謝，這是我的想法。這個問題在'爲什麼你會丟掉一段（可疑的有價值的）信息，如果僅僅在存儲和帶寬上花費你一個字節'這個問題上更具學術性。我碰到一個場景，我正在驗證一個文件名（與編碼的日期時間）對修改日期。因此，當閱讀非GMT時區的文件時，比較結果就顯得很糟糕。我當然可以解決它，但'只是想知道'。 – seanpj 2014-11-03 13:05:36

啊，這似乎更像是一個問題，是否有人會這樣做，我們沒有一個確切的答案。關於「爲什麼服務器使用UTC」，這取決於它。 * [服務器是否應將其時區設置爲GMT/UTC？]（服務器故障）（http://serverfault.com/questions/191331/should-servers-have-their-timezone-set-to-gmt-utc）*闡明瞭各種可能的優點/缺點。 – 2014-11-03 15:07:15

在服務器上使用UTC是相當標準的做法，它看起來像Google Drive也不例外。如果他們將日期存儲爲UTC，那麼就沒有理由存儲設備的特定時區。

如果您知道服務器將始終爲您提供UTC日期，那麼您可以將它們轉換回設備的本地時區。

來源

2014-11-02 19:49:18 Philio

謝謝，不用說，兩個答案都是正確的，我只是不能選擇兩個。 – seanpj 2014-11-03 13:07:27

Google Drive SDK getModifiedDate（）與setModifiedDate（）不同

回答

相關問題