商业规则应始终适用于民事诉讼时间（除非法律另有规定）。请注意，公民时间是一团糟，但这是人们使用的时间，所以这才是最重要的。

在内部，将时间戳保持在从大纪元开始的民用时间秒中。纪元并不特别重要（我喜欢Unix纪元），但它确实比其他纪元更容易。假装闰秒不存在，除非你正在做一些真正需要它们的事情（例如，卫星跟踪）。时间戳和显示时间之间的映射是应用DST规则的唯一点；规则经常变化（在全球范围内，一年几次；指责政客），所以你应该确保你没有硬编码地图。奥尔森的TZ数据库是无价的。

答案和其他数据摘要：（请添加您的答案）

Do:

无论何时，只要你指的是一个确切的时刻，都要根据不受夏令时影响的统一标准坚持时间。（GMT和UTC在这方面相当，但最好使用UTC一词。请注意，UTC也被称为祖鲁时间或Z时间。）相反，如果您选择使用本地时间值保存一个（过去的）时间，请包括该特定时间与UTC的本地时间偏移量（该偏移量可能会在一年中发生变化），以便以后可以明确地解释时间戳。在某些情况下，您可能需要同时存储UTC时间和等效的本地时间。通常这是通过两个单独的字段来完成的，但有些平台支持datetimeoffset类型，可以将这两个字段存储在一个字段中。当将时间戳存储为数值时，请使用Unix时间-这是自1970-01-01T00:00:00Z以来的整秒数（不包括闰秒）。如果需要更高的精度，请改用毫秒。该值应始终基于UTC，不进行任何时区调整。如果以后可能需要修改时间戳，请包括原始时区ID，以便确定偏移量是否与记录的原始值发生了变化。在安排未来事件时，通常首选当地时间而不是UTC，因为偏移量通常会发生变化。请参阅答案和博客文章。存储整个日期（如生日和周年纪念日）时，不要转换为UTC或任何其他时区。如果可能，请存储不包含时间的仅日期数据类型。如果这种类型不可用，请确保在解释值时始终忽略一天中的时间。如果您不能保证一天中的时间会被忽略，请选择中午12:00，而不是午夜00:00作为当天更安全的代表时间。请记住，时区偏移并不总是整数小时（例如，印度标准时间为UTC+05:30，尼泊尔使用UTC+05:45）。如果使用Java，请将Java.time用于Java 8和更高版本。java.time的大部分功能在ThreeTen Backport库中被向后移植到java 6和7。进一步适用于ThreeTenABP库中的早期Android（<26）。这些项目正式取代了现在处于维护模式的久负盛名的Joda Time。Joda Time、ThreeTen Backport、ThreeTen-Extra、java.Time类和JSR 310由同一个人Stephen Colebourne领导。如果使用.NET，请考虑使用Noda Time。如果使用没有Noda Time的.NET，请考虑DateTimeOffset通常比DateTime更好。如果使用Perl，请使用DateTime。如果使用Python 3.9或更高版本，请使用内置的zoneinfo处理时区。否则，请使用dateutil或arrow。通常可以避免使用较旧的pytz库。如果使用JavaScript，请避免使用旧的moment.js或moment时区库，因为它们不再被主动维护。有关详细信息，请参阅Moment.js项目状态。相反，考虑Luxon、date fns、day.js或js joda。如果使用PHP>5.2，请使用DateTime和DateTimeZone类提供的本地时区转换。使用DateTimeZone:：listAb缩略语（）时要小心-请参阅答案。要使PHP保持最新的Olson数据，请定期安装timezonedb PECL包；见答案。如果使用C++，请确保使用正确实现IANA时区数据库的库。其中包括cctz、ICU和霍华德·希南特的“tz”图书馆。在C++20中，后者被采用到标准＜chrono＞库中。不要将Boost用于时区转换。尽管其API声称支持标准IANA（又称“zoneinfo”）标识符，但它将它们粗略地映射到POSIX风格的数据，而没有考虑每个区域可能发生的丰富变化历史。（此外，该文件已无法维护。）如果使用Rust，请使用chrono。大多数业务规则使用民用时间，而不是UTC或GMT。因此，在应用应用程序逻辑之前，计划将UTC时间戳转换为本地时区。请记住，时区和偏移不是固定的，可能会改变。例如，历史上，美国和英国使用相同的日期来“向前冲”和“向后冲”。然而，在2007年，美国改变了时钟的日期。这意味着一年中的48周，伦敦时间和纽约时间相差5小时，4周（春季3小时，秋季1小时）相差4小时。在涉及多个区域的任何计算中，请注意类似的项目。考虑时间类型（实际事件时间、广播时间、相对时间、历史时间、重现时间），您需要存储哪些元素（时间戳、时区偏移和时区名称）以进行正确检索-请参阅本答案中的“时间类型”。让您的操作系统、数据库和应用程序tzdata文件在它们与世界其他地方之间保持同步。在服务器上，将硬件时钟和操作系统时钟设置为UTC，而不是本地时区。无论前面的要点是什么，服务器端代码（包括网站）都不应该期望服务器的本地时区是任何特定的。见答案。更喜欢在应用程序代码中逐个处理时区，而不是通过配置文件设置或默认值进行全局处理。在所有服务器上使用NTP服务。如果使用FAT32，请记住时间戳存储在本地时间，而不是UTC。当处理重复发生的事件（例如每周电视节目）时，请记住，时间会随着夏令时的变化而变化，并且不同时区的时间也会不同。始终将日期时间值查询为下限包含，上限不包含（>=，<）。

不要：

不要将“时区”（如美国/纽约）与“时区偏移”（如-05:00）混淆。它们是两种不同的东西。请参见时区标签wiki。不要使用JavaScript的Date对象在较旧的web浏览器中执行日期和时间计算，因为ECMAScript 5.1及更低版本有一个设计缺陷，可能会错误地使用夏时制。（这在ECMAScript 6/2015中已修复）。永远不要相信客户的时钟。这很可能是不正确的。不要告诉人们“在任何地方都要使用UTC”。这一广泛的建议是对本文档前面描述的几种有效场景的短视。相反，对正在处理的数据使用适当的时间参考。（时间戳可以使用UTC，但未来时间调度和仅日期值不应使用。）

测试：

测试时，请确保您测试了西半球、东半球、北半球和南半球的国家（事实上，在全球每四分之一的地区，共有4个地区），无论是否正在进行夏令时测试（给出8个），以及一个不使用夏令时的国家（另外4个国家覆盖所有地区，共12个）。测试DST转换，即当您当前处于夏季时，选择冬季的时间值。测试边界情况，例如UTC+12时区，夏令时，使当地时间UTC+13在夏季，甚至UTC+13的地方在冬季测试所有第三方库和应用程序，确保它们正确处理时区数据。至少测试半小时时区。

参考：

堆栈溢出上的详细时区标记wiki页面Olson数据库，又名Tz_databaseIETF奥尔森数据库维护程序草案时区和夏令时的来源ISO格式（ISO 8601）UnicodeConsortium提供的Olson数据库与Windows时区ID之间的映射维基百科上的时区页面StackOverflow问题标记为dstStackOverflow问题标记了时区处理DST-Microsoft DateTime最佳实践维基百科上的网络时间协议

其他：

游说你的代表结束DST这一令人厌恶的行为。我们总是希望。。。地球标准时间大厅

我最近在一个web应用程序中遇到了一个问题，在Ajax帖子中，返回到服务器端代码的日期时间与提供的日期时间不同。

这很可能与我在客户端上的JavaScript代码有关，该代码建立了以字符串形式发送回客户端的日期，因为JavaScript正在调整时区和夏时制，在某些浏览器中，何时应用夏时制的计算似乎与其他浏览器不同。

最后，我选择完全删除客户端上的日期和时间计算，并在一个整数键上返回到服务器，然后在服务器上转换为日期时间，以实现一致的转换。

我从中学习到：除非绝对必须，否则不要在web应用程序中使用JavaScript日期和时间计算。

将服务器设置为UTC，并确保所有服务器都配置为ntp或同等版本。

UTC避免了夏令时问题，服务器不同步可能会导致不可预测的结果，需要一段时间才能进行诊断。

我在两种类型的系统上找到了这一点，“轮班计划系统（例如工厂工人）”和“依赖天然气的管理系统”…

23小时和25小时的工作日是一个很难应付的问题，8小时的轮班需要7小时或9小时。问题是，你会发现每个客户，甚至客户的部门都有他们在这些特殊情况下创建的不同规则（通常没有记录）。

有些问题最好不要问客户，直到他们为您的“现成”软件支付了费用。很少有客户在购买软件时会提前考虑这类问题。

我认为在任何情况下，您都应该使用UTC记录时间，并在存储日期/时间之前转换为当地时间。然而，即使知道一个给定的时间是在哪，也很难使用夏令时和时区。

通常，在存储的时间戳中包含本地时间偏移量（包括DST偏移量）：如果您以后想在原始时区（和DST设置）中显示时间戳，仅使用UTC是不够的。

请记住，偏移量并不总是整数小时（例如，印度标准时间为UTC+05:30）。

例如，合适的格式是元组（unix时间，以分钟为单位的偏移量）或ISO 8601。

虽然我没有尝试过，但我认为时区调整的方法很有说服力，如下所示：

以UTC格式存储所有内容。创建具有三列的表TZOffsets：RegionClassId、StartDateTime和OffsetMinutes（int，以分钟为单位）。

在表中，存储本地时间更改的日期和时间列表，以及更改的程度。表中区域的数量和日期的数量取决于您需要支持的日期范围和世界范围。将其视为“历史”日期，尽管日期应包括未来，但实际的限制。

当您需要计算任何UTC时间的本地时间时，只需执行以下操作：

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

您可能希望在应用程序中缓存此表，并使用LINQ或其他类似方法进行查询，而不是访问数据库。

这些数据可以从公共域tz数据库中提取出来。

这种方法的优点和脚注：

代码中没有规则，您可以很容易地调整新区域或日期范围的偏移量。您不必支持每个日期或地区范围，您可以根据需要添加它们。地区不必直接对应于地缘政治边界，为了避免重复行（例如，美国大多数州都以相同的方式处理DST），您可以在另一个表中设置广泛的RegionClass条目，以链接到更传统的州、国家等列表。对于像美国这样的情况，DST的开始和结束日期在过去几年中发生了变化，这很容易处理。由于StartDateTime字段也可以存储时间，因此2:00 AM标准转换时间很容易处理。并非世界上任何地方都使用1小时夏令时。这很容易处理这些情况。数据表是跨平台的，可以是一个单独的开源项目，可以被几乎使用任何数据库平台或编程语言的开发人员使用。这可以用于与时区无关的偏移。例如，为调整地球自转而不时发生的1秒调整、对公历的历史调整等。由于这是在一个数据库表中，标准报表查询等可以利用数据，而无需遍历业务逻辑代码。如果您愿意，它还可以处理时区偏移，甚至可以考虑将一个地区分配给另一个时区的特殊历史情况。您所需要的只是一个初始日期，该日期为每个区域分配一个时区偏移量，并具有最小的开始日期。这将要求为每个时区创建至少一个区域，但允许您提出一些有趣的问题，例如：“1989年2月2日凌晨5:00，亚利桑那州尤马市和华盛顿州西雅图市之间的当地时间差是多少？”（只需从另一个SUM（）中减去一个）。

现在，这种方法或任何其他方法的唯一缺点是，从本地时间到GMT的转换并不完美，因为任何与时钟有负偏移的DST变化都会重复给定的本地时间。恐怕没有简单的方法来处理这个问题，这也是存储当地时间首先是坏消息的原因之一。

这是一个重要而令人惊讶的棘手问题。事实是，对于坚持时间没有完全令人满意的标准。例如，SQL标准和ISO格式（ISO 8601）显然不够。

从概念角度来看，通常处理两种类型的时间-日期数据，区分它们很方便（上述标准没有）：“物理时间”和“民事时间”。

时间的“物理”瞬间是物理学处理的连续宇宙时间线中的一个点（当然忽略了相对论）。例如，如果可以忽略闰秒，则可以在UTC中对这个概念进行适当的编码。

“民用”时间是遵循民用规范的日期时间规范：这里的时间点完全由一组日期时间字段（Y、M、D、H、MM、S、FS）加上TZ（时区规范）（实际上也是“日历”；但假设我们将讨论限于公历）来指定。时区和日历共同允许（原则上）从一个表示映射到另一个表示。但是，民用和物理时间瞬间是本质上不同类型的量值，它们应该在概念上分开并以不同的方式对待（一个类比：字节和字符串的数组）。

这个问题令人困惑，因为我们可以互换地谈论这些类型的事件，并且因为公民时代会受到政治变化的影响。这个问题（以及区分这些概念的必要性）在未来的事件中变得更加明显。示例（摘自我在这里的讨论。

约翰在日历上记录了某个日期的事件提醒2019-Jul-27，10:30:00，TZ=智利/圣地亚哥，（已偏移GMT-4，因此它对应于UTC 2019-Jul-27 14:30:00）。但总有一天未来，该国决定将TZ偏移量改为GMT-5。

现在，当这一天到来。。。该提醒是否应在

A） 2019-Jul-27 10:30:00智利/圣地亚哥=UTC时间2019-Jur-27 15:30:00？

or

B） 2019-Jul-27 9:3:00智利/圣地亚哥=UTC时间2019-Jul-27 14:30:00？

没有正确的答案，除非你知道约翰在概念上的意思当他告诉日历“请在2019年7月27日10:30:00给我打电话TZ=智利/圣地亚哥”。

他是说“公民约会时间”吗10:30“）？在这种情况下，A）是正确答案。

或者他是指“物理上的瞬间”，连续波中的一个点我们宇宙的时间线，比如，“下一次日食在这种情况下，答案B）是正确的。

一些Date/Time API正确地实现了这一区别：其中的Jodatime是下一个（第三个！）Java DateTime API（JSR 310）的基础。

如果您碰巧维护的数据库系统在DST活动的情况下运行，请仔细检查它们是否需要在秋季过渡期间关闭。Mandy DBS（或其他系统）不喜欢在同一时间点（本地）两次通过，这正是当你在秋天将时钟拨回时发生的情况。SAP采用了一种（IMHO真的很好）变通方法解决了这一问题——他们没有让时钟倒转，而是让内部时钟以正常速度的一半运行两个小时。。。

您需要了解Olson-tz数据库，可从ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/.它每年更新多次，以应对世界各地不同国家在冬季和夏季（标准时间和夏令时）之间切换的时间（以及是否切换）的最后时刻变化。2009年，最后一次发布是2009年；2010年为2010n；2011年为2011n；2012年5月底，发布时间为2012c。注意，在两个独立的存档（tzcode20xxy.tar.gz和tzdata20xxy.tar.gz）中有一组代码来管理数据和实际时区数据本身。代码和数据都在公共域中。

这是时区名称的来源，如America/Los_Angeles（和同义词，如US/Pacific）。

如果你需要跟踪不同的区域，那么你需要奥尔森数据库。正如其他人所建议的，您还希望以固定格式（UTC通常是所选的格式）存储数据，并记录生成数据的时区。您可能需要区分时间与UTC的偏移量和时区名称；这会在以后产生影响。此外，知道当前是2010-03-28T23:47:00-07:00（美国/太平洋）可能会或可能不会帮助您解释值2010-11-15T12:30-这可能是在PST（太平洋标准时间）而不是PDT（太平洋夏令时）中指定的。

标准的C库接口对这类东西没有太大的帮助。

奥尔森的数据发生了变化，部分原因是A·D·奥尔森很快就要退休了，另一部分原因是对维护者的版权侵权诉讼（现已驳回）。时区数据库现在由互联网号码分配机构IANA负责管理，并且在首页有一个“时区数据库”链接。讨论邮件列表现在是tz@iana.org; 公告列表是tz-announce@iana.org.

跨越“计算机时间”和“人类时间”的界限是一场噩梦。主要原因是，时区和夏令时的规则没有一种标准。各国可以随时自由更改时区和夏令时规则，他们也可以这样做。

一些国家，例如以色列、巴西，每年都会决定何时实行夏令时，因此无法提前知道夏令时何时生效。其他人对DST何时生效有固定的规则。其他国家并不完全使用夏令时。

时区不必与格林尼治标准时间相差整整一小时。尼泊尔为+5.45。甚至还有+13的时区。这意味着：

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

都是同一时间，但3天不同！

对于时区的缩写，以及它们在夏令时中的变化，也没有明确的标准，因此您最终会遇到这样的情况：

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

最好的建议是尽可能远离当地时间，尽可能坚持UTC。仅在最后一刻转换为当地时间。

测试时，请确保您测试了西半球和东半球的国家，其中既有正在进行的夏令时，也有未使用夏令时的国家（共6个）。

我不知道我能为上面的答案补充什么，但我有几点：

时间类型

您应该考虑四种不同的时间：

事件时间：例如，国际体育赛事发生的时间，或加冕/死亡等。这取决于事件的时区，而不是观众的时区。电视时间：例如，一个特定的电视节目在世界各地的当地时间晚上9点播出。当考虑在你的网站上发布（比如美国偶像）结果时，这一点很重要相对时间：例如：这个问题将在21小时内结束。这很容易显示重复播放时间：例如：每周一晚上9点播放电视节目，即使夏令时改变。

还有历史/备用时间。这些都很烦人，因为它们可能无法映射回标准时间。例如：朱利安日期，根据土星的阴历，克林贡日历。

在UTC中存储开始/结束时间戳效果良好。对于1，您需要与事件一起存储事件时区名称+偏移量。对于2，您需要为每个区域存储一个本地时间标识符，并为每个观众存储一个当地时区名称+偏移量（如果您遇到困难，可以从IP中导出）。对于3，以UTC秒存储，不需要时区。4是1或2的特殊情况，这取决于它是全局事件还是本地事件，但您还需要存储在时间戳创建的，以便您可以判断在创建此事件之前或之后是否更改了时区定义。如果需要显示历史数据，这是必要的。

存储时间

始终以UTC存储时间转换为显示的本地时间（本地时间由查看数据的用户定义）存储时区时，需要名称、时间戳和偏移量。这是必需的，因为政府有时会更改时区的含义（例如：美国政府更改了夏令时日期），而您的应用程序需要优雅地处理事情。。。例如：DST规则更改前后LOST剧集显示的确切时间戳。

偏移和名称

上述示例如下：

足球世界杯决赛发生在南非（UTC+2-SAST）2010年7月11日19:00 UTC。

有了这些信息，即使南非时区定义发生变化，我们也可以从历史上确定2010年WCS决赛的确切时间，并能够在观众查询数据库时以当地时区向他们显示。

系统时间

您还需要保持操作系统、数据库和应用程序tzdata文件彼此同步，并与世界其他地方同步，并在升级时进行广泛测试。你所依赖的第三方应用程序没有正确处理TZ更改，这并非闻所未闻。

确保硬件时钟设置为UTC，如果您在世界各地运行服务器，请确保其操作系统也配置为使用UTC。当您需要从多个时区的服务器复制每小时轮换一次的apache日志文件时，这一点变得很明显。仅当所有文件都以相同的时区命名时，才能按文件名对它们进行排序。这也意味着，当你从一个盒子到另一个盒子进行ssh时，你不必在脑子里计算日期，也不需要比较时间戳。

此外，在所有盒子上运行ntpd。

客户

永远不要相信从客户端计算机获得的时间戳是有效的。例如，Date:HTTP标头或javascript Date.getTime（）调用。当这些值用作不透明标识符时，或者当在同一客户端上的单个会话中进行日期计算时，它们都很好，但不要试图将这些值与服务器上的值进行交叉引用。您的客户机不运行NTP，并且可能不一定有用于BIOS时钟的工作电池。

琐事

最后，政府有时会做出非常奇怪的事情：

荷兰的标准时间是正好19分32.13秒在1909-05-01年法律规定的UTC之前通过1937-06-30。此时区不能使用HH:MM格式。

好的，我想我完了。

明确关注点的架构分离-准确地知道哪个层与用户交互，并且必须更改规范表示（UTC）的日期时间。非UTC日期时间是表示（遵循用户本地时区），UTC时间是模型（对于后端和中间层仍然是唯一的）。

此外，决定你的实际受众是什么，你不需要服务什么，你在哪里划分界限。除非你在那里有重要的客户，否则不要接触异国情调的日历，然后考虑为该地区单独的面向用户的服务器。

若您可以获取并维护用户的位置，则可以使用位置进行系统的日期时间转换（例如.NET区域性或SQL表），但如果日期时间对您的用户至关重要，则为最终用户提供一种选择覆盖的方式。

如果涉及历史审计义务（例如准确地告诉亚利桑那州的Jo在2年前的9月支付账单的时间），则记录UTC和当地时间（您的转换表会随着时间的推移而改变）。

为批量提供的数据（如文件、web服务等）定义时间参考时区。如果东海岸公司在加利福尼亚州设有数据中心，您需要询问并了解他们使用什么作为标准，而不是假设其中之一。

不要相信嵌入在日期时间文本表示中的时区偏移，也不要接受解析和跟踪它们。相反，始终要求明确定义时区和/或参考区域。你可以很容易地用PST偏移量接收时间，但时间实际上是EST，因为这是客户端的参考时间，记录只是在PST中的服务器上导出的。

还有一件事，确保服务器应用了最新的夏令时补丁。

去年，我们遇到了这样一种情况，北美用户在三周内的时间里，即使我们使用的是基于UTC的系统，我们的时间也总是比以前少一个小时。

最后证明是服务器。他们只需要应用最新的修补程序（Windows Server 2003）。

在处理存储在FAT32文件系统中的时间戳时要小心——它总是保存在本地时间坐标中（包括DST——请参阅msdn文章）。被那一块烧伤了。

如果您的设计能够适应，请避免同时转换本地时间！

我知道对一些人来说，这可能听起来很疯狂，但想想用户体验：用户处理接近的相对日期（今天、昨天、下周一）比绝对日期（2010.09.17，星期五-9月17日）的速度要快。当你仔细考虑时，时区（和DST）的准确度越接近现在（）就越重要，所以如果你可以用+/-1或2周的相对格式表示日期/日期时间，其余的日期可以是UTC，这对95%的用户来说并不重要。

通过这种方式，您可以以UTC存储所有日期，并以UTC进行相对比较，只需向用户显示超出相对日期阈值的UTC日期。

这也适用于用户输入（但通常以更有限的方式）。从只有{昨天、今天、明天、下周一、下周四}的下拉列表中进行选择，对于用户来说，比日期选择器更简单、更容易。日期选择器是表单填充中最令人痛苦的部分。当然，这并不适用于所有情况，但您可以看到，它只需要一点巧妙的设计就可以使其非常强大。

对于PHP：

PHP>5.2中的DateTimeZone类已经基于其他人提到的Olson DB，因此，如果您在PHP中而不是在DB中进行时区转换，则不必使用（难以理解的）Olson文件。

然而，PHP的更新频率不如Olson DB，因此仅使用PHPs时区转换可能会给您留下过时的DST信息，并影响数据的正确性。虽然这种情况预计不会经常发生，但如果您在全球拥有大量用户，这种情况可能会发生。

要解决上述问题，请使用timezonedb pecl包。它的功能是更新PHP的时区数据。根据更新的频率安装此软件包。（我不确定这个软件包的更新是否完全遵循奥尔森的更新，但它的更新频率似乎至少非常接近奥尔森更新的频率。）

实际上，kernel32.dll不导出SystemTimeToTzSpecificLocation。但是，它确实导出以下两个：SystemTimeToTzSpecificLocalTime和TzSpecificLocalTimeToSystemTime。。。

我只想指出两件似乎不准确或至少令人困惑的事情：

始终按照统一的标准坚持时间，而不是受夏令时影响。GMT和UTC已被不同的人，尽管UTC似乎最常被提及。

对于（几乎）所有实际的计算目的来说，UTC实际上是GMT。除非你看到一个分数秒的时间戳，否则你要处理的是GMT，这使得这种区分变得多余。

在以下情况下按原样包括本地时间偏移（包括DST偏移）：存储时间戳。

时间戳始终以GMT表示，因此没有偏移量。

在处理数据库（特别是MySQL，但这适用于大多数数据库）时，我发现很难存储UTC。

默认情况下，数据库通常使用服务器日期时间（即CURRENT_TIMESTAMP）。您可能无法更改服务器时区。即使您能够更改时区，您也可能有第三方代码希望服务器时区是本地的。

我发现，只需在数据库中存储服务器日期时间，然后让数据库在SQL语句中将存储的日期时间转换回UTC（即UNIX_TIMESTAMP（））就更容易了。之后，您可以在代码中使用日期时间作为UTC。

如果您100%控制服务器和所有代码，那么最好将服务器时区更改为UTC。

您正在使用.NET框架吗？如果是这样的话，让我向您介绍一下与.NET3.5一起添加的DateTimeOffset类型。

此结构同时包含DateTime和Offset（TimeSpan），后者指定DateTimeOffset实例的日期和时间与协调世界时（UTC）之间的差异。

DateTimeOffset.Now静态方法将返回DateTimeOffset由当前（本地）时间和本地偏移组成的实例（如操作系统的区域信息中所定义）。DateTimeOffset.UtcNow静态方法将返回DateTimeOffset实例包含UTC中的当前时间（如如果你在格林威治）。

其他有用的类型是TimeZone和TimeZoneInfo类。

永远不要只依赖像这样的构造函数

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

当某个日期时间由于DST而不存在时，它们可以抛出异常。相反，构建自己的方法来创建这样的日期。在它们中，捕捉由于DST而发生的任何异常，并使用转换偏移调整所需的时间。根据时区，夏令时可能会在不同的日期和时间（甚至巴西的午夜）发生。

对于网络来说，规则没有那么复杂。。。

服务器端，使用UTC客户端，使用Olson原因：UTC偏移量不是夏令时安全的（例如，纽约是一年中的EST（UTC-5小时）部分，EDT（UTC-4小时）部分）。对于客户端时区确定，您有两个选项：1） 用户设置区域（更安全）资源：Web就绪的Olson-tz HTML下拉列表和JSON2） 自动检测区域资源：jsTimezoneDetect

剩下的只是使用服务器端日期时间库进行UTC/本地转换。很好去。。。

对于那些在.NET上挣扎的人，看看使用DateTimeOffset和/或TimeZoneInfo是否值得。

如果您想使用IANA/Olson时区，或者发现内置类型不足以满足您的需要，请查看Noda time，它为.NET提供了更智能的日期和时间API。

PHP的DateTimeZone:：listAbstrations（）输出

此PHP方法返回一个包含一些“主要”时区（如CEST）的关联数组，这些时区本身包含更具体的“地理”时区（例如欧洲/阿姆斯特丹）。

如果您使用这些时区及其偏移/DST信息，请务必了解以下信息：

似乎每个时区的所有不同偏移量/DST配置（包括历史配置）都包含在内！

例如，欧洲/阿姆斯特丹可以在该函数的输出中找到六次。两次出现（偏移量1172/4772）是1937年之前使用的阿姆斯特丹时间；两个（1200/4800）用于1937年至1940年间使用的时间；两个（3600/4800）是1940年以来使用的时间。

因此，您不能依赖此函数返回的当前正确/正在使用的偏移量/DST信息！

如果您想知道某个时区的当前偏移量/DST，您必须执行以下操作：

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

以下是我的经验：-

（不需要任何第三方库）

在服务器端，以UTC格式存储时间，以便数据库中的所有日期/时间值都采用单一标准，而不考虑用户、服务器、时区或DST的位置。在UI层或发送给用户的电子邮件中，您需要根据用户显示时间。为此，您需要有用户的时区偏移量，以便将此偏移量添加到数据库的UTC值中，这将导致用户的本地时间。您可以在用户注册时获取他们的时区偏移，也可以在web和移动平台中自动检测他们。对于网站，JavaScript的函数getTimezoneOffset（）方法是1.0版以来的标准，并且与所有浏览器兼容。（参考：http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp)

对于在服务器上运行的应用程序（包括网站和其他后端服务），应用程序应忽略服务器的时区设置。

常见的建议是将服务器的时区设置为UTC。这确实是一个很好的最佳实践，但对于不遵循其他最佳实践的应用程序来说，这是一个创可贴。例如，服务可能使用本地时间戳而不是基于UTC的时间戳写入日志文件，从而在夏时制回退转换期间产生歧义。将服务器的时区设置为UTC将修复该应用程序。然而，真正的解决办法是应用程序首先使用UTC进行日志记录。

服务器端代码（包括网站）不应期望服务器的本地时区是任何特定的。

在某些语言中，本地时区很容易进入应用程序代码。例如，.NET中的DateTime.ToUniversalTime方法将从本地时区转换为UTC，DateTime.Now属性返回本地时区中的当前时间。此外，JavaScript中的Date构造函数使用计算机的本地时区。像这样的例子还有很多。练习防御性编程很重要，避免任何使用计算机本地时区设置的代码。

使用本地时区保留客户端代码，如桌面应用程序、移动应用程序和客户端JavaScript。

汤姆·斯科特（Tom Scott）在《计算机爱好者》频道的YouTube上关于时区的视频也对这一话题进行了精彩有趣的描述。示例包括：

萨摩亚（太平洋中的一个岛屿）将其时区提前24小时，以便于与澳大利亚和新西兰的贸易，西岸有两个人口在不同的时区，18世纪从儒略历到格里高利历的变化日历（发生在20世纪的俄罗斯）。

仅举一个例子来证明，处理时间是描述的巨大混乱，你永远不会自满。在本页的几个地方，闰秒被忽略了。

几年前，Android操作系统使用GPS卫星获取UTC时间参考，但忽略了GPS卫星不使用闰秒的事实。没有人注意到，直到除夕夜出现了混乱，苹果手机用户和安卓手机用户相隔约15秒进行倒计时。

我想它已经被修复了，但你永远不知道这些“小细节”什么时候会回来困扰你。

永远不要在没有UTC偏移（或时区参考）的情况下存储本地时间-如何不这样做的示例包括C¹中的FAT32和结构tm了解时区是一组UTC偏移（例如，冬季+0100，夏季+0200）切换发生的时间规则（可能会随着时间的推移而改变：例如，在20世纪90年代，欧盟将切换统一为3月和10月的最后一个星期日，标准时间02:00/夏令时03:00；之前成员国之间有所不同）。

¹struct tm的一些实现确实存储UTC偏移量，但这并未将其纳入标准。