簡短問題：SQL Server中的日期格式
什麼是SQL Server中使用的最佳日期格式？
長說明：
我們正在將我們的數據庫從mysql轉換爲SQL Server。在mysql中，我們總是使用int(11)來避免夏令時問題，如果我們在mysql中做同樣的事情（或者是DATETIME夠好）？
日期的使用各不相同。大多數情況下，他們只是提供有關發生各種事情的信息（用於記錄目的）。有時他們習慣於下單工作。
我們正在使用2005（嘆氣），但我很想聽聽2008年的情況。
我一直使用DATETIME存儲時間MSSQL服務器。它使日期和時間函數變得非常簡單 - 我不知道需要編寫多少自定義代碼才能在使用int進行日期/時間處理時獲得相同級別的功能和速度。爲了解決夏令時問題，您可以使用UTC存儲日期和時間，而不是服務器時間。您可以使用DateTime.UtcNow和getutcdate()，而不是使用DateTime.Now或getDate()。
它看起來像DateTime.UtcNow（）將允許我們用正確的時間填充日期時間字段。我們必須特別注意把客戶的時間投入到現場，但無論如何您總是需要這樣做。 另一種解決方案是使用DATETIMEOFFSET，但因爲我們現在使用的是2005年，所以這不是我們的選擇。 – 2009-11-16 16:08:06
我認爲日期應該總是保存爲日期類型（帶時區，時間部分在必要時排除）。
看到這裏的可能性（假設你使用SQL Server 2008）：
我同意戴夫K，所有日期應該作爲日期數據類型存儲。
這就是說，是否存在將日期存儲爲其他類型的特定原因？如果您要經歷從日期格式轉換爲其他類型的麻煩，並且可能稍後再回到日期格式，那麼所有這些工作的原因是什麼？
這都是關於不轉換。一旦你有當地時間的日期，你不能分辨我們回滾當天的第一個和第二個上午兩點之間的區別。 – 2009-11-16 16:05:28
這可能是將日期存儲在UTC而不是本地時區的一個很好的理由。 – 2009-11-18 02:30:31
這取決於您需要什麼以及您的數據傳輸的距離，以及您要使用的SQL Server版本。 2008有一些2005年沒有的新日期數據類型。
的easies選項通常是日期/時間存儲在datetime類型列，並始終保存在UTC時區的時間。這樣你就不會遇到節省日光的問題。然後，您可以明顯地將時間轉換爲客戶端用於顯示值的任何時區。
那些告訴你只是總是使用日期時間的人沒有徹底地讀你的問題，並且錯過了你有夏令時問題的部分。通常我會推薦自己的日期時間，但有些情況下這種類型可能會讓你失望。
在這種情況下，由於您大概已經有了處理int => datetime轉換的代碼，您可以堅持這一點。另一方面，如果你打算使用sql server 2008（而不是2000或2005），有新的datetime2和datetimeoffset類型可能更適合你的需求，你可能會考慮重構。
有了SQL Server 2008，你獲取日期類型過多：
所以，挑選你的毒藥。
這是一個難以回答的問題，不理解日期的目的和解釋。請提供背景嗎？ – shahkalpesh 2009-11-13 19:11:56
使用紀元時間不一定總是避免DST問題。 – BalusC 2009-11-13 19:22:03
日期格式（11/12/2009 11月12日或12月11日）？或數據類型？ – gbn 2009-11-13 19:22:33