實際上它被支持,發生了什麼事是服務器端將本地DateTimeOffset轉換爲標準UTC。
例如發送實體有 -
sendEnt.DateTimeOffset
{2/25/2015 6:55:46 PM -08:00}
Date: {2/25/2015 12:00:00 AM}
DateTime: {2/25/2015 6:55:46 PM}
Day: 25
DayOfWeek: Wednesday
DayOfYear: 56
Hour: 18
LocalDateTime: {2/25/2015 6:55:46 PM}
Millisecond: 229
Minute: 55
Month: 2
Offset: {-08:00:00}
Second: 46
Ticks: 635604873462293981
TimeOfDay: {18:55:46.2293981}
UtcDateTime: {2/26/2015 2:55:46 AM}
UtcTicks: 635605161462293981
則返回的實體有 -
retrievedEntity.DateTimeOffset
{2/26/2015 2:55:46 AM +00:00}
Date: {2/26/2015 12:00:00 AM}
DateTime: {2/26/2015 2:55:46 AM}
Day: 26
DayOfWeek: Thursday
DayOfYear: 57
Hour: 2
LocalDateTime: {2/25/2015 6:55:46 PM}
Millisecond: 229
Minute: 55
Month: 2
Offset: {00:00:00}
Second: 46
Ticks: 635605161462293981
TimeOfDay: {02:55:46.2293981}
UtcDateTime: {2/26/2015 2:55:46 AM}
UtcTicks: 635605161462293981
Year: 2015
服務器將返回UTC的DateTimeOffset,因爲沒有辦法弄清楚,如果最終用戶在發送時使用本地或UTC時間創建DateTimeOffset。
我正在投票結束這個問題作爲題外話,因爲它看起來像是MS團隊有任何原因的選擇(時間限制?)。在這裏問這是要求推測。 – Eddy 2015-02-23 14:28:34
我不同意它正在呼籲投機。作爲提出有關Azure的問題的兩個建議論壇之一(他們建議的其他論壇是MSDN),Microsoft鏈接到Stack Overflow。在這裏提出這個問題是呼籲知道答案的人迴應。如果有人不知道這個問題的答案,但是想把推測當作事實,那麼這就是他們的問題,而不是問題的問題。 – 2016-01-30 07:38:26