一般我们给一条记录增加时间记录，唯一的标识某一个时间点。例如我对数据进行一次操作，或者添加一条数据，都需要记录操作完成的时刻。简单的使用
datetime.now ;//<span style="font-size:18px;">获取本机当前时间</span>
那么这条数据传送到数据空就是这样的：2016-01-27 15:25:25.290 是yyyy-MM-dd hh：mm：ss.xxx的。。
那么问题就来 ，如果我将它转换为string类型显示到文本框中，p.operatingTime.ToString() 却得到的不是正确数据：而是0001/01/01 00:00:00。。
试了好几种方法：
方法一：
datetime.now.tostring();//结果正确，但是从数据中查询到的数据都不是即时时间。而且转换为string类型，与数据中的datetime类型也会发生冲突。pass
方法二：
time =convert.todatetime（b.logical_check_dt）.tostring("yyyyMMdd")
time =datetime.parse(b.logical_check_dt）.tostring("yyyyMMdd")
convert没有todatetime方法 只有tostring ；
time =datetime.parse(b.logical_check_dt）.tostring("yyyyMMdd") 提示:
与"System.dataTime.parse(string)" 最匹配的重载方法具有一些无效参数，参数1无法从System.dataTime? 转换为string这个最终查询的数据也是不符合需求。pass
后面就反思哪里出现了问题，其实是病急乱投医了，对于题目中类型的基本知识认识还比较薄，赶紧去网上找了很多的资料来看。总结如下：
LINQ to SQL支持以下DateTime方法。但是，SQL Server和CLR的DateTime类型在范围和计时周期精度上不同，如下表：
类型 |
最小值 |
最大值 |
计时周期 |
|---|---|---|---|
System.DateTime |
0001 年 1 月 1 日 |
9999 年 12 月 31 日 |
100 毫微秒（0.0000001 秒） |
T-SQL DateTime |
1753 年 1 月 1 日 |
9999 年 12 月 31 日 |
3.33… 毫秒（0.0033333 秒） |
T-SQL SmallDateTime |
1900 年 1 月 1 日 |
2079 年 6 月 6 日 |
1 分钟（60 秒） |
CLR DateTime 类型与SQL Server类型相比，前者范围更大、精度更高。因此来自SQL Server的数据用CLR类型表示时，绝不会损失量值或精度。但如果反过来的话，则范围可能会减小，精度可能会降低；SQL Server日期不存在TimeZone概念，而在CLR中支持这个功能。
我们在LINQ to SQL查询使用以当地时间、UTC 或固定时间要自己执行转换。
知道问题在哪里了吧！
原来看似简单的转换关系，，其中因为范围和精度的不同，经过两次转换后的时间就不是之前的时间了。。。