C#和JAVA中Ticks的不同含义

Anonymity | | 访问(196)

  做一个Android客户端,服务器用.NET的webservice做,需要获取服务器时间,于是在webservice中添加一方法,返回当前时间.Ticks的值。long类型

  结果发现在android客户端取出long值再转化为DateTime后和原本的服务器时间不一样

  百度了一下,得出结果特来花个三分钟对自己胡诌两句。

  闲话少说(已经说了不少),C#“DataTime.Now.Ticks”虽然的确也是 long(Int64) 类型的,但其数值的时间单位和 Java 那个(例如用“Calendar.getInstance().getTimeInMillis()”取得的long数值)完全不一样。

  C#中的通过DateTime取得的是100 nanosecond(100纳秒,10-7秒)

  而JAVA中取得的是1 millisecond(1毫秒,10-3秒)

  我心又想,单位不同,我给它转化一下就完了呗,调试一下但结果依不如我所愿。原来坑爹的还在后头。经过一番考究,C#中是从0001-01-01 00:00:00.000 开始算到目标时间的,而JAVA呢,是从 1970-01-01 00:00:00.000 开始算的毫秒数,那这样差别就不是一点点了。

  归纳总结能力不强,接下来截取网上贴子一份

  所以,除了数值采用的单位不同,二者计数的时间起点也不同。最后的结论就是,如果想用 .NET 的 System.DateTime.Now.Ticks 来实现 Java 的java.util.Calendar.getInstance().getTimeInMillis() 的话,你可以采取类似“(DateTime.Now.Ticks - new DateTime(1970, 1, 1).Ticks) / 1//0000”的办法,当然,我是用的“(DateTime.Now.Ticks - 621355968000000000) / 10000”,一个意思一个意思。

 java.util.Calendar.getTimeInMillis()System.DateTime.Ticks
数据类型 longlong
时间单位millisecond100 nanosecond
计时起点1970-01-01 00:00:00.0000001-01-01 00:00:00.000
//事后有热心的朋友提醒我,像我这样对 long 做除法会出误差(不能整除的时候),他们 Java Developer 都用 BigDecimal,不然会被笑话的。那行,赶紧的,.NET 里就用//Decimal 吧?  
public long getTimeInMillis()  
{  
    return Decimal.ToInt64(Decimal.Divide(DateTime.Now.Ticks - 621355968000000000, 10000));  
}  
//再后来,发现这其实是一个 Unix 时间和 .NET 时间表示法的相互转换问题。
//老白这才想起来,Linux 时间就是从 Epoch 开始算的,只是当时不知道 1970-01-01 00:00:00.//000 有个学名叫“Epoch”。  
//还没完,请往下看!!!  
//重要补充:热心读者 mobdx_19840908 敏锐地指出了本文的致命错误(参见评论)~~~ 简单说来就是使用 DateTime.Now 的时候没有注意时区问题!老白自己也在上文中说了
//Java 是以 UTC 为基准的,而经查证,.NET 中与其对应的是 DateTime.UtcNow 而非 DateTime.Now!  
//所以,最后的结论就是:  
return Decimal.ToInt64(Decimal.Divide(DateTime.Now.Ticks - new DateTime(1970, 1, 1, 8, 0, 0).Ticks, 10000))  
//或者  
return Decimal.ToInt64(Decimal.Divide(DateTime.UtcNow.Ticks - 621355968000000000, 10000));