時間戳（UnixTimestamp）與 《2038年問題》

時間戳是從格林威治時間1970年01月01日00時00分00秒(北京時間1970年01月01日08時00分00秒)起至現在的總秒數。

現在時間戳的長度是十位（1435113975--2015/6/24 10:46:15）。

要到 2286/11/21 01:46:40 才會變成11位（10000000000），距離現在還有 271年。

 

不同時區獲取的時間不一樣，生成的時間戳會不一樣，比如中國是東八區(+8)，美國東部是西五區(-5)，兩地的時差是13小時，北京比紐約要早13個小時；

一般從中國的12月15日乘飛機去美國， 到達時間就是美國的12月15日，在中國是12月16日。

這樣就導致跨時區驗證時間戳會不准的情況。

 

所以要把日期協調成世界時間。

C#中 DateTime.ToUniversalTime 方法會把本地時間協調成世界時間。

測試代碼：

 

string date = DateTime.Now.ToString();//本地時間
string dateAmerica = DateTime.Now.AddHours(-13).ToString();//模擬美國東部時間
object back = (DateTime.Parse(date).ToUniversalTime().Ticks - 621355968000000000) / 10000000;//協調全球時間的時間戳
object back2 = (DateTime.Parse(date).Ticks - 621355968000000000) / 10000000;//不協調全球時間的時間戳
object backA = (DateTime.Parse(dateAmerica).Ticks - 621355968000000000) / 10000000;//模擬美國東部時間的時間戳
Console.WriteLine("時間：" + date);
Console.WriteLine("協調全球時間的時間戳：" + back);
Console.WriteLine("時間戳的類型：" + back.GetType());
Console.WriteLine("時間戳的長度：" + back.ToString().Length);
Console.WriteLine("不協調全球時間的時間戳：" + back2);
Console.WriteLine("此時美國時間的時間戳：" + backA);

 

為什么要減去621355968000000000？

因為 DateTime.Ticks 表示自 0001 年 1 月 1 日午夜 12:00:00（表示 DateTime.MinValue）以來經過的以 100 納秒為間隔的間隔數。 它不包括歸因於閏秒的嘀嗒數。

其實是減去 0001 年 1 月 1 日午夜 12:00:00 到 1970年01月01日00時00分00秒 之間的秒數

 

輸出：

 

《2038年問題》

在計算機應用上，2038年問題可能會導致某些軟件在2038年無法正常工作。所有使用UNIX時 間表示時間的程序都將受其影響，因為它們以自1970年1月1日經過的秒數（忽略閏秒）來表示時間。這種時間表示法在類Unix（Unix-like）操 作系統上是一個標准，並會影響以其C編程語言開發給其他大部份操作系統使用的軟件。在大部份的32位操作系統上，此“time_t”數據模式使用一個有正 負號的32位元整數(signedint32)存儲計算的秒數。依照此“time_t”標准，在此格式能被表示的最后時間是2038年1月19日 03:14:07，星期二（UTC）。超過此一瞬間，時間將會被掩蓋（wrap around）且在內部被表示為一個負數，並造成程序無法工作，因為它們無法將此時間識別為2038年，而可能會依個別實作而跳回1970年或1901 年。錯誤的計算及動作可能因此產生。

 

其實就是在32位系統上，長度溢出導致的異常。