C#之中DateTime轉unix時間戳，莫名其妙多出八個小時(8:0:0)的解決辦法

c#之中表示時間的類型是DateTime，其中並無直接獲取unix時間戳的方法，而是經過Ticks屬性進行計算。

Unix時間戳是從1970年1月1日0:0:0開始計算，Ticks則從0001年1月1日開始計算，單位是100納秒數，因此減去1970年1月1日的Ticks以後還得除以一個很是大的數字，網上搜一下通常會搜到這樣的辦法：

 

DateTime t = new DateTime(2018, 12, 26, 0, 0, 0);//須要轉爲unix時間戳的時間

DateTime dt1970 = new DateTime(1970, 1, 1, 0, 0, 0); //1970年1月1日0:0:0的Ticks納秒數

long unix_timestamp = (t.Ticks - dt1970.Ticks) / (10000 * 1000); //10000個100納秒爲1毫秒，1000毫秒爲1秒，因此須要除以10000 * 1000

 

固然還有簡單粗暴一點的：

DateTime t = new DateTime(2018, 12, 26, 0, 0, 0);//須要轉爲unix時間戳的時間

long unix_timestamp = (t.Ticks - 621355968000000000) / (10000 * 1000); //直接寫上1970年1月1日0:0:0的納秒數

 

可是不管是哪一個方法，最終獲得的結果都是1545782400，在網上找個unix時間戳工具算一下，能夠看到，這是2018/12/26 8:0:0

怎麼回事？明明寫的是2018/12/26 0:0:0，爲何會多出八個小時？

網上全部相關文章之中都沒有提到這一點，這是個很大的坑！

其實緣由很簡單，Datetime的Ticks，以格林尼治時間爲準，而咱們本地的時間是北京時間，好比本地時間的好比2018/12/26 0:0:0，並不等於格林尼治時間的好比2018/12/26 0:0:0，而是剛好差了八個小時，因此直接作減法獲得的答案是正確的，但卻不是咱們想要的！反而會形成不少問題。

若想得到正常的，北京時間的unix時間戳，請使用以下代碼（在1970年的Ticks以前加上一個ToLocalTime()方法）：

DateTime t = new DateTime(2018, 12, 26, 0, 0, 0);//須要轉爲unix時間戳的時間

DateTime dt1970 = new DateTime(1970, 1, 1, 0, 0, 0); //1970年1月1日0:0:0的Ticks納秒數

long unix_timestamp = (t.Ticks - dt1970.ToLocalTime().Ticks) / (10000 * 1000); //加上ToLocalTime方法，將格林尼治時間1970/1/1轉爲北京時間