2013-03-21 406 views
11

我知道這是一個很常見的問題,但我不覺得我發現的答案真正解決了問題。我將概述我的具體使用案例,並提供其他SO答案和網絡中的信息摘要。時間戳:iso8601 vs unix時間戳

對於我正在撰寫的服務數據庫條目的創建和存儲都在移動設備和我們的網站上,並且需要同步兩種方式。我們目前正在針對Android和iOS,它們都使用sqlite作爲關係數據庫。服務器端使用Django和MySQL在Python中實現,但其他解決方案可能會在未來取代它。

將按照本答案概述的思路實施同步:https://stackoverflow.com/a/5052208/2076094。爲了同步,我們將使用僅由服務器設置並同步到客戶端的時間戳,用於創建和更新對象的last_synced_date和時間戳。由於對象是指用戶在特定時間執行的操作,因此它們也具有時間戳信息。

我的問題只涉及這些時間戳的內部時間表示。用戶界面中的用戶表示是內部表示的本地化和格式化版本。在實現語言和用於表示時間戳的不同數據庫中有很多不同的方法。相當多的研究之後,似乎有隻有有效的解決方案左:

  • Unix的時間
  • ISO8601

article這是Hacker News上(兩次),建議使用UNIX時間並提出了一個很好的論點。關於HN的討論,正如預料的那樣,在上述兩點和其他一些方面存在分歧。

到目前爲止我的結論是,Unix時間戳更容易處理,但似乎並不是在Django中常見的方式。幾乎所有我從Django教程中發現的代碼示例到很多其他站點都使用models.py中的DateTimeField,它被映射到SQL中的某種日期字段,具體取決於所使用的數據庫。

使用ISO8601日期傳輸和存儲的缺點是需要分析它們以創建相應的實現語言的日期類型。這並不難,但有點煩人。對於我們使用的每種語言,您都需要一個(小)庫,或者至少需要比您希望的更多的代碼。這不是很漂亮,創建依賴關係,可能會稍微慢一些。 Unix時間時間戳在我知道的任何語言中都沒有這個問題。

另一件事是,您可以很容易地在數據庫中(和解析過程中)使用「智能」日期或時間戳字段發生麻煩。關於時間魔法的問題,有很多關於這個問題的問題。我的鏈接已達到限制,所以我無法發佈任何內容,但您可以輕鬆找到一些;)

我們可以使用不包含時區信息的簡化格式,並且始終使用UTC。我們只會使用UTC,但是如果您使用ISO8601,那麼您可能會使用普遍理解和明確的格式。 Unix時間總是用UTC,所以你永遠不必擔心。

當然,當您查看原始數據庫時,ISO8601的優點是人類可讀,並且在2038年之前不必重寫幾行代碼,但這似乎不能彌補缺點。

看來,寫出來的東西我已經有了我的答案;)無論如何,我很想知道別人的想法以及你在自己的項目中做了些什麼。請簡要介紹一下您的用例,以便其他人可以更好地分類您的輸入。

謝謝!

回答

0

感謝您提出的這個好問題。很難找到任何有關時間數據類型或時間標準/格式的信息,無論這稱爲什麼。過去幾天我一直在努力選擇正確的時間格式。 就像你,我在移動設備和網絡服務器中都編碼(更不用說也會有桌面應用程序)。 我的技術技能相當實證,我的背景研究是藝術,但我確實經常使用編碼。我問自己的主要問題是「我如何在移動設備,Web服務器(API或任何你想要調用的)和桌面應用程序之間獲得無縫的體驗?如何在事件發生時保持一致以及如何確保這個瞬間的表示在這個軟件星座的不同層次上是相同的?

正如你可能知道使用移動設備編碼意味着你正在使用SQLite數據庫和Web應用程序,主要意味着MySQL。對於我所能想象到的最令人頭疼的事情之一,我對使用時間數據從一張表到另一張表感到非常失望,可以選擇什麼?DateTime?Timestamp?哦,天哪,SQLite沒有內置時間數據類型...... Unix時間?好吧,沒問題,當然MySQL不會使用UNIX時間作爲標準...會太簡單...

我學到的是......如果你想把數據放在時間軸上,並說這是事件發生的時間軸上的時間點,那就使用時間戳(無論是UNIX還是MySQL的樣式,也就是ISO8601)。人類可讀性只是我的一個細節。沒有人應該閱讀數據庫表,計算機,並且你確實告訴計算機處理數據,以便人類能夠理解。但接下來是「什麼是時區?」的問題彈出...呃...它很糟糕...但是,嘿,將挖掘網絡的答案。

我自己我很驚訝,MySQL不使用UNIX時間,我認爲這是最標準和一致的時間。

我真的認爲圍繞這​​個問題的文檔更加輕鬆......我現在正在考慮編寫一些關於如何處理MySQL和SQLite的文章。我在這件事上浪費了3天的時間,試圖理解如何使它變得乾淨和簡單。我的結論,與現有的文件,你只是不能...:PI很可能是錯的......不管怎麼說,看看這個視頻顯示的關於MySQL中的時間數據處理鬥爭: http://www.youtube.com/watch?v=fp-etlirjbo

感謝張貼這個問題,這對我來說很有啓發。

乾杯,

+2

始終使用UTC時區,每當你需要一個本地時間轉換爲本地時間。 – 2015-10-05 08:58:53

+1

@AnthonyHunt ....爲什麼? Unix時間是一個數字。 *該值總是GMT *這是一個很大較短(UNIX時間戳需要一個32位整數,而時間戳需要ASCII的200位) *它的平臺/語言無關,並通過所有的編程語言 * 64位操作系統使用處理一個64位t_time整數,所以它會持續宇宙的熱死亡 所以我真的很好奇,爲什麼你會選擇犧牲移動性,大小和malь字符串解析? – Ancarius 2016-08-17 20:09:59