通常ISV在面對本地客戶時對時間相關的處理,一般都時區信息都是不敏感的。但是現在雲的世界里為了讓大家把時間處理的方式統一起來,雲上的服務都是以UTC時間為準的,現在如果作為一個ISV來說就算你面對的客戶只是本地用戶但是你打算利用雲來為你進行的應用提供更多的功能和便捷性時,你就需要採用UTC時間來處理
通常ISV在面對本地客戶時對時間相關的處理,一般都時區信息都是不敏感的。但是現在雲的世界里為了讓大家把時間處理的方式統一起來,雲上的服務都是以UTC時間為準的,現在如果作為一個ISV來說就算你面對的客戶只是本地用戶但是你打算利用雲來為你進行的應用提供更多的功能和便捷性時,你就需要採用UTC時間來處理跟相關的代碼了。
在SQL Server資料庫處理時間相關的數據時,我們常常會使用DateTime類型或者DateTime2類型來處理數據,其實早在SQL Server 2008發佈時,資料庫就開始支持DatetimeOffset數據類型了,DatetimeOffset天生出來就是為了處理時區問題的
參考上一個Blog 《Azure 上SQL Database(PaaS)Time Zone時區問題處理》,我們同樣要來解決時區的問題,我們創建appcount表時,我們採用下麵語句
CREATE TABLE [dbo].[appcount2]( [Id] [int] IDENTITY(1,1) NOT NULL, [createtime] [datetime] NULL, [CreatetimeWithOffset] [Datetimeoffset] NULL, PRIMARY KEY CLUSTERED (Id) )
插入數據時使用
INSERT INTO appcount(createtime,createtimewithoffset) VALUES(GetDate(),sysdatetimeoffset() AT TIME ZONE 'China Standard Time')
插入完數據我們將數據在查詢出來
我們會發現DateTimeOffset在處理時區問題時不管帶不帶時區的遷移語句的出來的時間都是正確的,但是DateTime欄位的出來的時間明顯就會有時間偏移錯誤。
我們用下麵的C#從.NET程式裡面將這些時間數據取出來會如何呢?
using (IDbConnection conn = new System.Data.SqlClient.SqlConnection(strConn)) { conn.Open(); var command = conn.CreateCommand(); command.CommandText = "Select id,createtime,CreatetimeWithOffset from appcount"; var reader = command.ExecuteReader(); while (reader.Read()) { var id = reader["id"]; var date = reader["createtime"]; var date2 = reader["createtimeWithOffset"]; var localDate = ((DateTimeOffset)date2).LocalDateTime; Console.WriteLine("id:{0},createtime:{1},DateTimeInOffSet:{2},localdate:{3}", id, date,date2, localDate); } reader.Close(); conn.Close(); }
這裡是代碼執行結果:
小結:
採用DatetimeOffset來存儲時間,通過DatetimeOffset來處理時間可以讓你的代碼更加穩健,更加國際範
相關文章:《Azure 上SQL Database(PaaS)Time Zone時區問題處理》