引言

　   DateTime資料型別是一個複雜的問題，複雜到足以讓你在編寫【將日期從Web伺服器返回到瀏覽器】簡單程式碼時感到困惑。

ASP.NET MVC 5和 Web API 2/ASP.NETCore 以不同方式序列化日期，這可能會給在一個Web應用程式中同時使用這兩個序列化的開發人員帶來更多混淆。

本文會盡量覆蓋 ASP.NET / ASP.NETCore 中與 Date/Time有關的歧義、引數繫結、序列化相關的知識點和坑位。 

 

Date/Time值歧義和應對策略

　　使用Datetime最大的問題在於歧義，整個地球分為24個時區，每個時區都有自己的本地時間

例如一個DateTime值指示了本地時間，這個值在同時區的其他系統依然標示了同一時間點； 但是在其他時區以外，這個DateTime值就會有各自的解釋。

電郵中若有 Sun ， 04， June 2019 9:45:29 +0800 說明信件傳送第時間是2019年6月04日，星期日，上午9點45分29秒，該地區領先UTC8小時 (+800，就是東八區時間)。 對於發這封郵件的時間，北京本地時9點45，倫敦是凌晨1點45 ......

　　正因為這個現狀，在Internet以及無線電通訊時，時間的統一很重要。

　　業界提出了不同的格式來明確地表示單一時間點， Web開發行業提出了不同的解決方案以明確定義時間值。

  UTC時間

　　在國際無線電通訊中，為避免各自為戰而普遍使用一個標準時間，稱為協調世界時（UTC）

 UTC是0時區的時間值，與格林威治標準時間（GMT）一樣，都與英國倫敦的當地時間相同

　　UTC能準確代表單一時間點，UTC 時間對於住在加利福尼亞和中國的人來說都是一樣的。

 如果把以上北京時間2019/06/04 09:45:29轉化為UTC時間，可以使用以下公式： UTC + 時區差 = 當地時間。

因為北京時間是東8區，所以這個點UTC時間是 2019/06/04 02:45:29（也可認為該值是倫敦時間）

 

開發者可以考慮的解決方案 是： 使用UTC時間儲存date/time、服務端維護、計算也使用UT時間、將UTC時間傳送到瀏覽器，瀏覽器javascript在Web頁上轉化為當地時間。

 ISO 8601

　　Web上有許多時間顯示格式，但最著名並大規模採用的是ISO-8601 標準。https://www.cl.cam.ac.uk/~mgk25/iso-time.html

當沒有更多資訊的時候，只包含Date/Time 的寫法被假定為當地時間，要指示該時間是UTC時間，可在Datetime值後面加上字母 z，

在Datetime值後面增加 +hh:mm、 +hhmm, -hh 可指示該時間值相對於UTC時間的偏移

// Date: 2016-10-12 10:18:42 UTC time
ISO 8601: 2016-10-11T10:18:42z

// Date: 2016-10-12 10:18:42 Pacific time， 表示該時間值相對於UTC時間值提前6小時
ISO 8601: 2016-10-11T10:18:42-06:00

 

.Net中關於Date/Time的實現

　　.Net 4.0+ 提供的各種結構已經全方位支援 date， timezone， timezone之間的轉化，足以解決開發者遇到的Date/Time相關的問題。

DateTime

　　DateTime 定義了一個特殊的date/time, 內建的Kind屬性提供了受限的時區資訊：

　　① DateTimeKind.UTC 指定了UTC的DateTime，明確定義了單一時間點

　　② DateTimeKind.Local 指示了本地時間，這個值在具有相同時區的其他系統依然能夠定義一個時間點，但是在其他時區以外，這個DateTime值會有不同解釋。

　　③ DateTimeKind.Unspecified 更沒有相容性，僅表示時間值

　　我們關注 DateTime.ToUniversalTime() 方法的表現，當DateTime被設定為Unspecified時候， ToUniversalTime會首先假定該值是 Local

// 以下程式碼的執行環境是北京時間
var dt1 = new DateTime(2019, 6, 4, 9, 45, 29, DateTimeKind.Local);
var dt1_temp = dt1.ToUniversalTime();

var dt2 = new DateTime(2019, 6, 4, 9, 45, 29, DateTimeKind.Utc);
var dt2_temp = dt2.ToUniversalTime();

var dt3 = new DateTime(2019, 6, 4, 9, 45, 29, DateTimeKind.Unspecified);
var dt3_temp = dt3.ToUniversalTime();

Console.WriteLine(dt1_temp.ToString());
Console.WriteLine(dt2_temp.ToString());
Console.WriteLine(dt3_temp.ToString());    // Unspecified DateTime在被應用ToUniversalTime 方法時會被假定是Local

output： 
2019/6/4 1:45:29
2019/6/4 9:45:29 
2019/6/4 1:45:29

 when to use datetime？

• 你只處理當地時間，你沒有跨越時區的計算

• 你只處理 UTC時間

• 處理抽象日期/時間（使用 Unspecified）：例如 跨國公司的跨時區門店都在早上9點開業

DateTimeOffset

表示時間點，通常表示為一天中相對於UTC時間的日期/時間，該結構體自然帶有相對於UTC時間的偏移資訊

when to use DateTimeOffset？

• 程式碼需要應對不同時區的時間值

• 時區之間相互轉化

• 需要進行跨時區的計算

https://docs.microsoft.com/en-us/dotnet/standard/datetime/converting-between-datetime-and-offset  

Date/Time 序列化

　　WebAPI 2 和ASP.NETCore 內建的JSON序列化器是 Newtonsoft.Json，JSON.NET將日期時間序列化為ISO-8601格式：

Date value	serialized value
DateTime.Now (Pacific time)	2016-10-11T19:25:34.8346658-07:00
DateTime.UtcNow	2016-10-12T01:25:34.8346658Z
new DateTime(2016, 6, 6, 4, 5,5 )	2016-06-06T04:05:05
new DateTimeOffset(new DateTime(2016, 6, 6, 4, 5,5 ), new TimeSpan(-2, 0,0))	2016-06-06T04:05:05-02:00

　　            

　　 

　　早期的ASP.NET MVC 內建的JSON Serializer 是System.Web.Script.Serialization.JavaScriptSerializer， 該序列化器將date序列化為時間戳：“\/Date(ticks)\/”， ticks 表示從1970-1-1 00:00:00 UTC（Unix Epoch）經歷的毫秒數，

這樣的格式在客戶端需要使用JavaScript做一些本地轉化， 轉化後的值無法體現時區。

JavaScriptSerializer還有更多缺點，現在社群鼓勵使用Json.Net 序列化器。

 

Date/Time字串轉換

　　在開發中，常涉及Date/Time 引數繫結和字串轉換， 當中也有一些坑位需要規避。

一個時間日期字串， 若沒有相對於UTC的偏移資訊，轉換後的DateTime物件的DateTimKind是Unspecified；

若指定了offset，轉換後的DateTime物件的DateTimeKind是Local， 並且時間值被調整到機器的當地時間。

最近我們生產環境WebSite再遷移到k8s叢集 (UTC時間)之後，就遇到這樣的問題:

訂單轉儲的預期是：北京時間2019-05-11--->2019-05-12

實際情況是在網站端轉換為Unspecified， 而進一步ToUniversalTime()過濾的時候，該時間段又被假定是機器的當地時間， 也就是說查詢時間段變成了： 倫敦時間2019-05-11--->2019-05-12

這樣自然與預期不符。

解決思路： 新增偏移資訊，告知明確的時間段： 2019-05-11 00:00:00+08:00 ----> 2019-05-12 00:00:00+08:00

       https://docs.microsoft.com/en-us/dotnet/standard/base-types/parsing-datetime         開發者每天都在使用的Date/Time有很多學問， 涉及Culture、Calendar、夏令時， 這裡只是淺談最常用的知識點和坑位。   作者：Julian_醬

感謝您的認真閱讀，如有問題請大膽斧正，如果您覺得本文對你有用，不妨幫忙點個或加關注。

本文版權歸作者所有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置註明本文的作者及原文連結，否則保留追究法律責任的權利。