在倉庫中處理時區？

Question

將一切都存儲在GMT？

以嵌入偏移量的方式存儲所有內容？

每次渲染時都要計算數學嗎？

顯示相對時間「1分鐘前」？

Answer 1

你必須以UTC存儲 - 如果你不這樣做，你的歷史報告和行爲在諸如夏令時之類的事情中會變得......有趣。 GMT是當地時間，受夏時制相對於UTC（不是）的影響。

如果您存儲本地時間，向不同時區的用戶演示可能是一個真正的混蛋。如果您的原始數據是UTC，則很容易調整到本地 - 只需添加用戶的偏移量即可完成！

Joel在其中一個播客中談到了這件事 - 他對store your data in the highest resolution possible（尋找'保真度'）說，因爲當它再次熄滅時你總是可以將它絆倒。這就是爲什麼我說把它作爲UTC存儲的原因，因爲當地時間你需要爲那些不在那個時區的人進行調整，這是很艱苦的工作。例如，當您儲存時間時，您是否需要儲存夏令時是否生效。育。

通常在過去的數據庫中，我存儲了兩個UTC用於排序，本地顯示時間。這樣，用戶和計算機都不會感到困惑。

現在，作爲顯示：當然，你可以做「3分鐘前」的事情，但只有當你存儲UTC時間時 - 否則，輸入不同時區的數據將顯示爲「-4小時前「，這會讓人大失所望。如果您要顯示實際時間，人們喜歡在當地時間使用它 - 如果數據輸入到多個時區，則只有在您存儲UTC時才能輕鬆完成。

Answer 2

個人而言，我看不到任何理由不將所有內容都存儲在GMT中，然後使用用戶本地時區顯示與它們相關的時間。

如果你想顯示相對時間，你顯然仍然需要時間和做翻譯，但如果你想做翻譯，我認爲GMT仍然是你最好的選擇。

Answer 3

我喜歡以GMT格式存儲並且只顯示相對（「大約10秒前」，「5個月前」）。用戶不需要查看大多數用例的實際時間戳。

當然有例外，單個應用程序可能有很多這樣的應用程序，所以它不可能是一個「一個真正的方法」的答案。需要強大審計能力（如投票）的事情，以及時間屬於話語領域（天文學，科學研究）的系統可能需要向用戶展示真正的時間戳。

雖然大多數應用程序只需簡單的相對時間就可以更容易理解。

Answer 4

所以我跑了一點MSSQL服務器的實驗。

我創建了一個表並添加了一個包含當前本地化時區（澳大利亞）的行。 然後我將我的日期時間更改爲GMT並添加了另一行。

即使這些行相隔大約10秒，它們也會出現在SQL服務器中，因爲它們相隔10小時。

如果沒有別的，它至少告訴我，我應該以conisitent的方式存儲日期，這對我來說，增加了將它們存儲爲GMT的參數的權重。

Answer 5

MS Dynamics存儲GMT，然後在用戶級別知道您的時區相對於GMT。然後它在您的時區顯示給您。

我以爲我會把它扔出去，因爲這是MS的一個非常大的團體，這就是他們如何決定處理它。

Answer 6

我通常只使用Unix時間。不一定是未來安全的，但它工作得很好。

Answer 7

始終以GMT（或UTC）存儲。從那裏很容易轉換到任何當地的時區值。

Answer 8

喬希以上是完全正確的，但我有一個細微的警告來解釋。對於未來的事件和時區，這是一個沒有正確答案的案例。

考慮重複約會的情況。它發生在格林威治標準時間0000（爲了簡單起見），即1200 NZST（新西蘭標準時間）和1000澳大利亞悉尼EST。

當夏令時在一個區域生效時，約會應該發生什麼？應該：

1a。如果TZ更改在 的區域內，約會的「所有者」（ 預訂了它），然後嘗試在相同的服務時鐘時間（例如上午10:00）保持在 ？
1b。如果 TZ的變化是在其他 會議參加者的區域之一，那麼沒有 變化

後果：它移動的 其他人一樣，出乎意料的是，由於 業主TZ的變化，但它保持 「在上午10點會議「至於 所有者而言。 '

'2。如上所述，但相反。

後果：會議所有者（上午10點會議成爲上午9點會議，或v/v），這可能是預期的但不方便。對於其他與會者來說，它們保持在同一時間段的時間，直到他們完成自己的TZ轉換。

兩者都不完美。考慮兩個約會的情況，其中一個由A人在當地時間上午10點預訂，另一個由B人以A人作爲參加者在上午9點預訂。如果A人和B人使用不同的TZ，那麼DST變化很容易導致他們變成雙倍預訂。

如果你的思想有點彎曲在這一點上，那麼我很明白。

這個例子背後的要點是，要正確地完成這些行爲，不僅需要知道當地時間的UTC版本，而且需要知道擁有者在預訂時的TZ（而不是偏移量） 。否則，你別無選擇，只能採取選擇2，默默無聞，甚至沒有通知任何人事情發生了變化，因爲格林尼治標準時間不會改變，只有演示文稿發生變化......對嗎？ （不，這是陷阱，當你的上午10點會議自己移動時，演示很重要）

我必須稱讚我的同事和朋友Jason Pollock的這種見解。請閱讀his view here，以及後續討論iCal and VTIMEZONE。

Answer 9

答案一如既往，是「依賴」。

這取決於您所描述的時間以及數據是如何提供給您的。 決定如何存儲時間值的關鍵是決定您是否因丟失時區而丟失信息，以及您的用戶不會感到意外。

將數據存儲在UTC time_t中有確定的好處 - 它是一個int值，允許快速排序和輕鬆存儲。

我認爲問題被分解成具體領域：

1. 歷史數據
2. 未來，短期數據
3. 未來，長期數據

用下面的子類對：

1. Sys TEM提供
2. 用戶提供的

讓我們來看看他們一次一個。

系統提供：我會建議以UTC運行系統，然後避免時區問題，並且不會再出現信息丟失（通常是UTC）。

歷史數據：這些都是一樣的系統日誌文件，進程統計，跟蹤，評論日期/時間等數據是不會改變的，而時區描述符是不會去修改。對於這種類型的數據，不管其提供的時區是什麼，通過以UTC存儲信息都不會丟失任何信息。因此，請刪除時區。

未來，長期數據：這些事件在未來或將持續發生。如果它們保持足夠長的時間，則時區描述符可以保證更改。這類數據的一個很好的例子是「每週管理會議」。這是一次輸入的數據，並且預計會永久運行。對於這些值，確定它是系統還是用戶提供很重要。對於用戶提供的數據，時間應該與創建者的時區一起存儲，否則會導致信息丟失。當時區定義更改並且創建者顯示的時間具有完全不同的值時，此信息丟失會變得明顯！

正如Bwooce所指出的，創作者和觀衆在不同的時區中存在一些混淆。在那種情況下，我希望應用程序能夠指出哪些時間值已經由於他們以前的位置的時區偏移而發生了移動。

未來短期數據：這是快速變爲歷史數據，或僅在短時間內有效的數據。例子可以是間隔計時器，評級轉換等。對於這些數據，由於可能性很低，定義將在創建值和歷史時間之間發生變化，因此可能會放棄刪除時區。但是，我發現這些價值觀有一個壞習慣，即成爲「未來長期數據」。

一旦你決定存儲時區，必須注意它的存儲方式。

• 不要將時區存儲爲偏移量或完整的描述符。

如果您將時區存儲爲偏移量，如果時區更改，您會怎麼做？你是否會瀏覽系統並對現有數據進行全面更改？如果你這樣做，你現在已經使任何歷史值不正確。這個故障的好例子是Oracle和iCal。 Oracle將時區信息存儲爲UTC的偏移量，iCal包含創建時區的完整描述符。

• 將它作爲名稱存儲。

這允許更改時區的定義而無需修改您擁有的現有值。它確實使排序更加困難，因爲如果時區數據更改，則生成的任何索引都可能無效。

如果開發人員繼續以UTC格式存儲所有內容，不考慮時區，我們將繼續看到我們在最後一批時區更改中看到的問題。

在一個組織中，祕書必須在夏令時之前打印出團隊的日曆，然後在更改後再打印出來。最後，他們比較了兩者並重新創建了所有已經遷移的約會。當然，他們錯過了幾次，直到舊的夏令時已經到來，並且時間再次變得正確時，還有幾個星期的痛苦。

Answer 10

我更喜歡隨時區存儲所有內容。客戶可以決定，它應該在稍後呈現的方式。 我最喜歡的圖書館是PostgreSQL-Database。

Answer 11

以GMT/UTC存儲所有內容對我來說似乎最合乎邏輯。然後，您可以在每個需要的時區顯示日期和時間。

幾個ceveats：

1. 如果時間僅指定爲 掛鐘時間，那就是 領導表示，那麼它是不是 絕對指定的時間。 您應該（也不能）在任何格林威治標準時將其轉換爲 。例如。每天早上9:00 AM。換句話說： 這是沒有（日期）的時間。
2. 如果 節省未來 預約的日期和時間，你應該使用 抵消由輸入 時區指定GMT和的時刻 本身。因此，如果在例如冬季在夏季製作的約會 西歐，它是+2：00, 所有雖然正常（冬令時） 抵消是+1：00。這將解決Bwooce 提到的日曆問題。
3. 當然，這適用於使用權 偏移而轉換成GMT 在任何特定 時區轉換回 日期和時間應用相同的 。

幸運的是，如果使用正確，（.NET）DateTime類型會照顧所有保存日曆等等的細節，當你知道它是如何工作的時候，所有這些都應該很容易。

Answer 12

看看這裏，w3c做了很好的回答。

看看用例。

http://www.w3.org/TR/timezone/

注意，他們建議存儲日期時間爲UTC不GMT，格林尼治標準時間受到日光節約時間。