日期时间是开发过程中最尝使用的数据类型之一，但是很多开发人员在使用过程中忽视了时间日期的一些特性。现在的应用越来越讲究“国际化”和“本地化”，它们的重要特征之一就是一些数据类型的格式或换算，日期时间是其中之一（其余还有货币，数字等等）。在进一步讨论开发中的日期时间问题之前，我们需要先理清有关时间的一些基础概念：
-
国际标准时间：为了让时间问题比较容易得到解决，国际上定义了国际标准时间（Universal Coordinated Time或Coordinated Universal Time）这一概念，它要求全球范围内都以零经度线上的时间作为国际上统一采用的标准时间。因为零经度线通过英国格林威治天文台，所以国际标准时间也称为格林威治时间（GMT，Greenwich Mean Time）。此外，它又被称为UTC（Universal Time Code）。很多朋友会被那么多名词和缩写所迷惑，其实它们都表示同一个概念。其中，UTC可能是国际标准时间最常用的称呼，在这片文章中我也将使用UTC时间来代指国际标准时间。
-
时区：理论上地球任意两个不同的经度的地点就有不同的“当地时间”，因此在地球东西方向移动丝毫就改变了当前位置的时间。但是追求这样的“精确”在大多数时候与场合都会显得非常麻烦，而且没有任何意义。为了解决这个问题，国际上又提出了时区（time zone）这个概念。按照时差的划分方法，从西经7.5度到东经7.5度划为“中区”，又称之为“零时区”。然后依次向东西两边每15度划分一个时区。例如，从东经7.5度到东经22.5度为东一区、西经22.5度到西经37.5度为西二区。整个地球被划分为24个时区，每个时区使用该区的中央经线的“当地时间”作为这个时区的时间。
-
地方时：地方时（Local Time）其实有两种概念：
- 第一种是指每个时区所用的时间，与中区的时间相比，向东时区的时间依次变晚，向西则依次变早。我们在表示某个时区的时间时，可以使用相对于UTC时间的表示法，例如东二区所用的时间为UTC +2，表示它比UTC时间要晚2小时。同理，西一区使用的时间为UTC -1。这种表示方法可以在很多场合看到。
- 由于地球被划分为不同的国家和地区，因此我们站在不同“土地”的角度上来看，“地方时”又有了另一个概念。例如中国，幅员辽阔，横跨64个经度，从东五区到东九区整整5个时区，但是几乎整个中国都使用北京所在的东八区的时间，正所谓“北京时间”，这也是中国在国际上所用的时间。但是并非每个国家都使用同一个时间，例如美国就使用了东部时间和西部时间，甚至还有冬令时和夏令时（例如在一些外企有跨国团队协作，在某一时刻往往就会有Email来通知，提醒从某月某日开始将采用哪种时间，因为从那时开始，美国人相对于中国的工作时间就改变了）。正因为有个这样的变化，其实搞清楚这种“地方时”远比第一种来的复杂。
-
时差：顾名思意，时差（time difference）指的是两个时间的时间差。理论上这是一个非常精确的值，但是事实上由于提出了时区的概念，时差在进行计算时往往就是整数个小时。
对于时间日期来说，最重要的可能就是“时差”问题，主流编程语言中表示日期时间对象都对于这个问题有着足够的支持，不过许多开发人员都会忽视这一点。这就是这片文章中最主要会谈论的问题。虽然大部分的应用可能都不涉及到“全球化”，但是我们还是有充分的理由来搞清楚时间方面的问题：
-
为了将应用推向其他市场作准备。有一条“准则”叫做“Think Global, Do Local”，这要求我们在设计和开发应用程序时都思考一下这方面的问题。例如我们一直所说的“使用utf-8作为网页的编码”就是这一准则的一个实践。在处理日期时间方面，我们经常会使用的一个实践就是“使用UTC时间作为存储”。目前流行的开发语言中的日期时间一般都会包含“时区”的概念，但是在例如Sql Server 2005等存储系统对于时区没有良好的支持。因此在将时间存入Sql Server 2005时，强烈建议先将日期时间转为UTC时间。
-
将应用程序的执行效果独立于部署环境。我们在开发时使用的很多功能会带上系统设置的时区，很多朋友在开发应用时会忽视这一点，这样如果将程序部署到时区设置不同的系统上（例如国外的虚拟主机服务），在运行时就会产生不同的结果。如果大家使用FxCop（包含在Windows SDK中）来检测自己的程序集就会发现，调用日期时间的无参数ToString方法违反了Globalization类别的一条准则。这是因为无参数的ToString方法返回结果会由当前线程的Culture（可以通过Thread.CurrentThread.CurrentCulture属性来获取或设置）来决定，而当前线程的Culture与系统设置相关。
-
可以轻松的开发出适合多地区浏览的应用。对于一个“国际化友好”的应用程序来说，往往我们是根据客户端的地域设置或者目前正浏览的市场设置来显示时间，这样在中国的用户和在美国的用户就不会因为时间产生误解。从这一点上又可以清楚地发现使用UTC时间作为存储是多么的重要，只有这样，才能方便地做到“国际化”友好，
个人认为，时间问题其实是应用程序国际化中最容易解决的问题，因为货币会涉及到汇率换算，文字又涉及到翻译等等，而在时间日期问题上我们只要符合一定的良好实践即可。我们在处理时间问题时往往都应该留个心眼，例如遇到开发过程中怎么时间莫名其妙的差了8个小时的问题，就应该敏感地想到会不会是因为日期时间在时区问题上出现了差错，因为我们的开发机一般总是用了北京时间（UTC +8）嘛。:)
之所谓得到写这个系列的灵感，是因为一个朋友在向我反馈ASP.NET AJAX中调用Web Service方法时在日期时间上出现的问题。原本我只是想简单地针对这个问题进行解释（其实并不是bug，只是因为在开发时忽视了时区问题），但是发现描述时涉及到了太多的内容，因此我想趁此机会深入一下时间方面的问题，以及在使用JavaScript和.NET Framework在开发时的要点和实践。具体内容将在今后的文章中进行详细描述。
本文转自 jeffz 51CTO博客，原文链接：http://blog.51cto.com/jeffz/59901，如需转载请自行联系原作者
