自定义日期格式化字符串里有个坑，昨晚坑掉我们半夜的时间

(先吐槽一下，刚才新添加随笔的时候居然没有出现编辑器工具，结果文章保存后没有任何排版格式，不是我故意不分段啊。)

昨天晚上很悲催，忙到半夜12点多，最后才发现是被日期时间格式化的时间格式说明符给坑了。

事情的起因很简单，页面上有个datawindow控件要接受一个日期字符串来刷新数据，本地测试怎么测都妥妥的，数据该刷多少刷多少，该新增多少就新增多少；但是部署到服务器上之后就邪乎了，数据可以新增，但是计算值都为零。

由于该控件下新增的数据要用先刷新出来的数据做基础进行运算，所以一开始我们以为是计算数据的时候出现问题，但服务器是正式环境，没有VS，也不允许远程调试，于是只好修改代码，将数据运算过程中的公式和数值等写入日志，看有没有异常。结果很郁闷，公式正确，但来源基础数值都是0，这说明公式计算没问题，是数据来源出了问题。

于是继续改代码，把datawindow的行数输出到日志，终于发现，该控件根本就没有加载任何数据，没有了基础数据，后面的计算数据自然全是0了。但为什么会没有数据呢，明明在本地测试的万无一失了，此时已经接近半夜11点了，我们都几近崩溃了。

后来终于想到，这个控件要接受一个日期字符串，会不会是它的问题？代码已经改了N次，记录了N多原以为会出错的信息了，于是又加上一条日期字符串的输出。这次终于把坑找到了，测试结果发现日期字符串没有按照预期的格式输出！太坑了！但为什么我们在本地测试却没问题呢？ 大家可以看一下我们的日期格式化字符串的代码：


你是不是觉得会输出类似“2015/03/17”这样的字符串呢？恭喜你，你和我们一样也掉进坑里了。

事实上在不同的机器上会输出不尽相同的格式，一般是“2015/03/17”、“2015-03-17”或者“2015.03.17”之中的一种，肯定不会完全如预期的输出“2015/03/17”这样的格式。

最后借助万能的百度，终于知道这个坑隐藏的太深了，根源在于，日期格式化字符串中，字符“/”不是普通字符，而是一个转义符，它代表的是系统日期格式中定义的分隔符。也就是如果你的系统日期分隔符定义成“-”或“.”就会输出“2015-03-17”或者“2015.03.17”，而不会输出“2015/03/17”。经过比对服务器上和本机上的系统日期自定义格式的分隔符，发现的确是默认分隔符不一样，本地的是“/”，而服务器上的是“-”，所以同样的格式化代码却出了不一样的格式。

这个让人崩溃的问题最后就是一个转义符的事，但却耗掉了我们半晚上的时间，有时候就是这样，结果很简单过程却很曲折。看来有些细节的知识还是需要好好的钻研一下的，那么在不改变系统设置的情况下怎么才能让“/”输出在日期格式化字符串中呢？代码如下：