企业级的系统和我们平常桌面、手机上运行的软件有着很重要的区别，其中比较重要的一点就是环境（包括第三方的系统的不同接口以及各系统的不同版本、安全性、数据等）比较复杂，所以不论在产品维护还是部署过程中要考虑的因素都有很多。
偶们的系统的最新版本最近在南非上线，遇到了不少问题。昨天晚上本屌和同事解决了一个比较“严重”的问题（因为影响到系统的核心功能），发现是由“国际化”的问题所引起。虽然找到问题的原因并不困难，但是要在客户的环境解决还是费了不少精力（因为不能从产品中去修复这个问题，即使给一个补丁按照公司的流程至少也需要半个月）。之前我也帮运营团队解决过一部分这类问题，在工作中也看到过不少，那么这里一并记录一下吧。希望大家在以后的开发过程中多加注意。
一、数据库的日期时间格式问题
这应该是几乎所有的系统在部署到不同国家的客户环境中都会遇到的问题，卡死不少程序，耗费无数人力。因此这是在数据存储时一定要格外注意的地方。这里以SQL Server为例。
（1）数据表中的时间格式
对于日期和时间，SQL Server中提供了datetime、datetime2、datetimeoffset、date、time这几种类型。我个人推荐只使用datetime和datetime2，因为这两个类型与.NET的程序兼容性最好（都可以直接对应成DateTime）。在.NET中也提供了DateTimeOffset类型，但是在一些比较老的语言中并不支持，为了兼容使用datetime就足够了。使用其他类型会牵扯到转型的问题，应尽量避免以免产生额外的问题。
需要注意的是，datetime支持的最小时间是1753年，因此要避免在程序中直接使用DateTime.MinValue传到数据库中，否则会产生out-of-range的错误。
在一些古老的系统中，会使用int类型来存储日期，因为int会占4个字节，所以两者互相转型是支持的，使用convert进行转型即可，一般不会有什么问题。
（2）时区的问题
建议在数据库中所有数据都以UTC时间保存，在显示的时候客户端根据本地的时区进行处理，因此在存储过程中一定要注意把时间转换成UTC时间。如果不保存UTC时间，以后在显示和迁移的过程中难免会发生混乱，所以尽量不要使用当地的时间来保存，即使系统只在一个地区使用。
在设计SSRS报表时，也要注意时区的问题。由于数据库中存储的是UTC时间，所以在调用Reporting Service服务的时候应把用户输入的时间转换成UTC时间后传给报表服务。在显示的使用，使用如下代码格式化单元格：
这样做的好处是：在程序编译后会生成几个文件夹，这些文件夹按语言的名字来命名（比如zh-cn表示简体中文），文件夹中有资源文件的dll。在系统启动的时候可以让用户选一种语言，然后设置CultureInfo，这样系统就会自动去相应的文件夹取这个语言包里的字符串。还有一个很人性化的功能，就是如果在对应语言的资源文件中没有找到这个字符串，就会从默认的语言包中取出并显示。（比如我们产品有繁体中文的语言包，如果有些地方没有进行翻译，在繁体中文的语言包中就不会有这个字符串，此时系统会显示出英文语言包中的字符串。）
以上是我遇到的处理国际化问题的一些典型例子，如果你遇到了一些这样的问题，欢迎指出并共同探讨。