十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最近开发碰到一个关于DateTime转换的业务,几个系统的区域语言(CultureInfo)设置都不一致,位置是控制面板-时钟、语言区域-更改日期、时间和数字格式。
超过10余年行业经验,技术领先,服务至上的经营模式,全靠网络和口碑获得客户,为自己降低成本,也就是为客户降低成本。到目前业务范围包括了:成都做网站、网站设计、外贸营销网站建设,成都网站推广,成都网站优化,整体网络托管,重庆小程序开发,微信开发,成都app软件开发,同时也可以让客户的网站和网络营销和我们一样获得订单和生意!
线上服务器 en-GB
开发环境 zh-CN
测试服务器 en-US
代码主要涉及两个方法DateTime.ToString()和DateTime.Parse(string),如果各种转换都在同一个application上跑基本是不会有问题,比如:
var d = DateTime.Parse("2013-03-11 00:56:20"); var dStr = d.ToString(); var dNew = DateTime.Parse(dStr);
这样的代码能完全正常的,现在的场景会涉及到一个Console exe(简称A)和IIS上一个Web Service(简称B),麻烦就出现了。
A的CultureInfo默认是读取系统配置,在A中执行
var d = DateTime.Parse("2013-03-11 00:56:20"); var dStr = d.ToString();
三个环境的dStr都不一致
en-GB 11/03/2013 00:56:20
zh-CN 2013/3/11 00:56:20
en-US 11/3/2013 0:56:20 AM
接下去将dStr传入B,在B中执行
var dNew = DateTime.Parse(dStr);
这时候会发现DateTime.Parse无法识别dStr,这是因为IIS本身有自己默认的CultureInfo设置CultureInfo.InvariantCulture,这个默认配置并不区分en-GB还哦zh-CN等,所以几乎无法识别与CultureInfo有关的日期格式。
解决方案:
1. 设置IIS的CultureInfo为对应值,或者给DateTime.Parse指定对应的CultureInfo,这个方法弊端很大,因为Web Service本身是提供服务给客户端的,如果限制了一个CultureInfo,对来自各个区域的客户端是不公平的,例如设置成zh-CN,我想英国的客户端会疯掉;
2. IIS保持CultureInfo.InvariantCulture默认配置,那么只好设置客户端的CultureInfo,直接也指定成CultureInfo.InvariantCulture,大家都公平就最好了;
总之就是让大家的CultureInfo都一致,不要随便在DateTime.Parse指定CultureInfo我觉得是最好的实践,除非你无法控制dStr的来源格式。