我希望使这个问题及其答案成为处理夏令时的权威指南，特别是处理实际的转换。
如果你有什么要补充的，请做
许多系统都依赖于保持准确的时间，问题在于由于夏令时导致的时间变化——向前或向后移动时钟。
例如，在接单系统中具有取决于订单时间的业务规则——如果时钟发生变化，则规则可能不那么清晰。订单的时间应该如何坚持？当然有无数种场景——这只是一个说明性的场景。
同样重要的是，如果不是更重要的话：
我会对编程、操作系统、数据持久性和该问题的其他相关方面感兴趣。
一般的答案很好，但我也想看看细节，特别是如果它们只在一个平台上可用。
做：
datetimeoffset可以将两者都存储在单个字段中的类型。1970-01-01T00:00:00Z（不包括闰秒）。如果您需要更高的精度，请改用毫秒。此值应始终基于 UTC，无需任何时区调整。DateTimeOffset通常是比 .NET 更好的选择DateTime。DateTime, 和DateTimeZone类提供的本地时区转换。使用时要小心DateTimeZone::listAbbreviations()——见答案。为了让 PHP 保持最新的 Olson 数据，请定期安装timezonedb PECL 包；见答案。<chrono>库中。
>=, <)。不：
America/New_York与“时区偏移”，例如-05:00. 他们是两个不同的东西。请参阅时区标签 wiki。Date对象在较旧的 Web 浏览器中执行日期和时间计算，因为 ECMAScript 5.1 及更低版本存在设计缺陷，可能会错误地使用夏令时。（这已在 ECMAScript 6 / 2015 中修复）。测试：
参考：
timezone标签 wiki 页面dsttimezone其他：
I'm not sure what I can add to the answers above, but here are a few points from me:
There are four different times you should consider:
There is also Historic/alternate time. These are annoying because they may not map back to standard time. Eg: Julian dates, dates according to a Lunar calendar on Saturn, The Klingon calendar.
Storing start/end timestamps in UTC works well. For 1, you need an event timezone name + offset stored along with the event. For 2, you need a local time identifier stored with each region and a local timezone name + offset stored for every viewer (it's possible to derive this from the IP if you're in a crunch). For 3, store in UTC seconds and no need for timezones. 4 is a special case of 1 or 2 depending on whether it's a global or a local event, but you also need to store a created at timestamp so you can tell if a timezone definition changed before or after this event was created. This is necessary if you need to show historic data.
An example of the above would be:
The soccer world cup finals game happened in South Africa (UTC+2--SAST) on July 11, 2010 at 19:00 UTC.
With this information, we can historically determine the exact time when the 2010 WCS finals took place even if the South African timezone definition changes, and be able to display that to viewers in their local timezone at the time when they query the database.
You also need to keep your OS, database and application tzdata files in sync, both with each other, and with the rest of the world, and test extensively when you upgrade. It's not unheard of that a third party app that you depend on did not handle a TZ change correctly.
Make sure hardware clocks are set to UTC, and if you're running servers around the world, make sure their OSes are configured to use UTC as well. This becomes apparent when you need to copy hourly rotated apache log files from servers in multiple timezones. Sorting them by filename only works if all files are named with the same timezone. It also means that you don't have to do date math in your head when you ssh from one box to another and need to compare timestamps.
Also, run ntpd on all boxes.
Never trust the timestamp you get from a client machine as valid. For example, the Date: HTTP headers, or a javascript Date.getTime() call. These are fine when used as opaque identifiers, or when doing date math during a single session on the same client, but don't try to cross-reference these values with something you have on the server. Your clients don't run NTP, and may not necessarily have a working battery for their BIOS clock.
Finally, governments will sometimes do very weird things:
Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. This time zone cannot be represented exactly using the HH:MM format.
Ok, I think I'm done.
这是一个重要且令人惊讶的棘手问题。事实是，坚持时间没有完全令人满意的标准。例如，SQL 标准和 ISO 格式（ISO 8601）显然是不够的。
从概念上看，通常处理两种时间-日期数据，便于区分（上述标准没有）：“物理时间”和“民用时间”。
“物理”时间瞬间是物理学处理的连续宇宙时间线中的一个点（当然忽略相对论）。例如，这个概念可以在 UTC 中充分编码持久化（如果您可以忽略闰秒）。
“民事”时间是遵循民事规范的日期时间规范：这里的时间点完全由一组日期时间字段（Y、M、D、H、MM、S、FS）加上 TZ（时区规范）指定（实际上也是“日历”；但假设我们将讨论限制在公历）。时区和日历共同允许（原则上）从一种表示映射到另一种表示。但是民用和物理时刻是根本不同类型的量级，它们应该在概念上保持分离和区别对待（类比：字节数组和字符串）。
这个问题令人困惑，因为我们可以互换地谈论这些类型的事件，并且因为民间时代会受到政治变化的影响。对于未来的事件，问题（以及区分这些概念的需要）变得更加明显。示例（取自我在此处的讨论。
John 在他的日历中记录了 datetime 某个事件的提醒
2019-Jul-27, 10:30:00， TZ= Chile/Santiago，（它具有偏移 GMT-4，因此它对应于 UTC 2019-Jul-27 14:30:00）。但在未来的某一天，该国决定将 TZ 偏移更改为 GMT-5。
现在，当这一天到来时……该提醒是否应该在
A) 2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00?
或者
B) 2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00?
没有正确答案，除非人们知道约翰在告诉日历“请致电我2019-Jul-27, 10:30:00
TZ=Chile/Santiago”时的概念含义。
他的意思是“公民日期时间”（“我所在城市的时钟显示 10:30”）吗？在这种情况下，A) 是正确答案。
还是他的意思是“时间的物理瞬间”，即我们宇宙连续时间线上的一个点，例如，“下一次日食发生时”。在这种情况下，答案 B) 是正确的。
一些日期/时间 API 正确区分了这一点：其中，Jodatime是下一个（第三个！）Java DateTime API (JSR 310) 的基础。
对关注点进行清晰的架构分离 - 准确了解哪个层与用户交互，并且必须为/从规范表示 (UTC) 更改日期时间。非 UTC 日期时间是演示文稿（遵循用户本地时区），UTC 时间是模型（对于后端和中间层仍然是唯一的）。
另外，决定你的实际受众是什么，你不需要服务什么以及你在哪里划清界限。除非您确实在那里有重要客户，否则不要触摸异国情调的日历，然后考虑仅针对该地区使用单独的面向用户的服务器。
如果您可以获取和维护用户的位置，请使用位置进行系统的日期时间转换（例如 .NET 文化或 SQL 表），但如果日期时间对您的用户至关重要，则为最终用户提供一种选择覆盖的方法。
如果涉及历史审计义务（例如准确告诉 AZ 的 Jo 2 年前 9 月何时支付账单），请保留 UTC 和本地时间作为记录（您的转换表会随着时间的推移而改变）。
为大量传入的数据（如文件、Web 服务等）定义时间参考时区。假设东海岸公司在 CA 有数据中心 - 您需要询问并知道他们使用什么作为标准，而不是假设其中一个。
不要相信嵌入在日期时间的文本表示中的时区偏移，也不要接受解析和遵循它们。相反，始终要求必须明确定义时区和/或参考区。您可以轻松地接收带有 PST 偏移的时间，但该时间实际上是 EST，因为这是客户端的参考时间，并且记录只是在 PST 中的服务器上导出的。
您需要了解 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）。
如果您需要跟踪不同的区域，那么您需要 Olson 数据库。正如其他人建议的那样，您还希望以固定格式存储数据（通常选择 UTC）以及生成数据的时区记录。您可能想要区分当时与 UTC 的偏移量和时区名称；这可以在以后有所作为。此外，知道当前是 2010-03-28T23:47:00-07:00 （美国/太平洋）可能会或可能不会帮助您解释值 2010-11-15T12:30 ——这可能在 PST 中指定（太平洋标准时间）而不是 PDT（太平洋夏令时间）。
标准 C 库接口对这类东西没有太大帮助。
Olson 数据已经移动，部分原因是 AD Olson 将很快退休，部分原因是有一项（现已驳回）针对维护者侵犯版权的法律诉讼。时区数据库现在由互联网号码分配机构IANA管理，首页上有一个指向“时区数据库”的链接。讨论邮件列表现在是tz@iana.org；公告列表是tz-announce@iana.org。
通常，在存储的时间戳中包含本地时间偏移（包括 DST 偏移）：如果您以后想要在其原始时区（和 DST 设置）中显示时间戳，仅 UTC 是不够的。
请记住，偏移量并不总是整数小时数（例如，印度标准时间是 UTC+05:30）。
例如，合适的格式是元组（unix 时间，以分钟为单位的偏移量）或ISO 8601。
跨越“计算机时间”和“人的时间”的界限是一场噩梦。主要的一点是，管理时区和夏令时的规则没有任何标准。国家/地区可以随时更改其时区和 DST 规则，而且确实如此。
以色列、巴西等一些国家每年都决定何时实行夏令时，因此无法提前知道（是否）夏令时生效。其他人有关于 DST 何时生效的固定（ish）规则。其他国家根本不使用 DST。
时区不必与 GMT 相差整小时。尼泊尔是+5.45。甚至还有 +13 的时区。这意味着：
SUN 23:00 in Howland Island (-12)
MON 11:00 GMT
TUE 00:00 in Tonga (+13)
都是相同的时间，但 3 天不同！
时区的缩写也没有明确的标准，以及它们在 DST 中如何变化，所以你最终会得到这样的结果：
AST Arab Standard Time UTC+03
AST Arabian Standard Time UTC+04
AST Arabic Standard Time UTC+03
最好的建议是尽可能远离当地时间，并尽可能坚持使用 UTC。仅在最后一刻转换为当地时间。
测试时，请确保您测试的是东西半球的国家/地区，其中既有正在进行的 DST，也有未使用 DST 的国家（共 6 个）。
对于 PHP：
PHP > 5.2 中的 DateTimeZone 类已经基于其他人提到的 Olson DB，因此如果您在 PHP 中而不是在 DB 中进行时区转换，则可以免除使用（难以理解的）Olson 文件。
但是，PHP 的更新频率不如 Olson DB，因此仅使用 PHP 的时区转换可能会给您留下过时的 DST 信息并影响数据的正确性。虽然预计这种情况不会经常发生，但它可能会发生，并且如果您在全球拥有大量用户群，就会发生这种情况。
要解决上述问题，请使用timezonedb pecl 包。它的功能是更新 PHP 的时区数据。安装此软件包的频率与更新频率一样高。（我不确定这个包的更新是否完全遵循 Olson 更新，但它的更新频率似乎至少非常接近 Olson 更新的频率。）
如果您的设计可以容纳它，请一起避免本地时间转换！
我知道对某些人来说这听起来很疯狂，但想想 UX：用户一目了然地处理较近的相对日期（今天、昨天、下周一）比绝对日期（2010.09.17，星期五 9 月 17 日）快。而且当您考虑更多时，时区（和 DST）的准确性越接近 date 越重要now()，因此如果您可以以相对格式表示日期/日期时间 +/- 1 或 2 周，其余的日期可以是 UTC，这对 95% 的用户来说并不重要。
这样，您可以以 UTC 存储所有日期并以 UTC 进行相对比较，并简单地显示您的相对日期阈值之外的用户 UTC 日期。
这也可以应用于用户输入（但通常以更有限的方式）。从只有{昨天、今天、明天、下周一、下周四}的下拉列表中选择对用户来说比日期选择器简单得多。日期选择器是表单填写中最容易引起痛苦的组件之一。当然，这并不适用于所有情况，但您可以看到只需要一点巧妙的设计就可以使其非常强大。
虽然我还没有尝试过，但我认为引人注目的时区调整方法如下：
以 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 数据库中提取。
这种方法的优点和脚注：
现在，这种方法或任何其他方法的唯一缺点是从本地时间到 GMT 的转换并不完美，因为任何对时钟具有负偏移的 DST 更改都会重复给定的本地时间。恐怕没有简单的方法来处理这个问题，这是存储当地时间首先是坏消息的一个原因。
我最近在一个 Web 应用程序中遇到了一个问题，在 Ajax 回发中，返回到我的服务器端代码的日期时间与提供的日期时间不同。
这很可能与我在客户端上的 JavaScript 代码有关，该代码构建了作为字符串回发到客户端的日期，因为 JavaScript 正在调整时区和夏令时，并且在某些浏览器中计算何时应用夏令时似乎与其他人不同。
最后，我选择完全删除客户端上的日期和时间计算，并在一个整数键上发回我的服务器，然后将其转换为服务器上的日期时间，以实现一致的转换。
我从中学到的：除非绝对必须，否则不要在 Web 应用程序中使用 JavaScript 日期和时间计算。
我已经在两种类型的系统上实现了这一点，“轮班计划系统（例如工厂工人）”和“气体依赖管理系统）......</p>
每天工作 23 和 25 小时是一件很痛苦的事情，8 小时轮班也需要 7 小时或 9 小时。问题是你会发现每个客户，甚至客户的部门都有他们在这些特殊情况下所做的事情创建的不同规则（通常没有记录）。
有些问题最好在客户为您的“现成”软件付费之前不要问他们。很少有客户在购买软件时预先考虑到此类问题。
我认为在所有情况下，您都应该以 UTC 记录时间，并在存储日期/时间之前转换为本地时间。然而，使用夏令时和时区，即使知道给定的时间是多少也很难。
对于网络来说，规则并没有那么复杂......
其余的只是使用服务器端日期时间库的 UTC/本地转换。好去...
对于在服务器上运行的应用程序，包括网站和其他后端服务，应用程序应该忽略服务器的时区设置。
常见的建议是将服务器的时区设置为 UTC。这确实是一个很好的最佳实践，但对于不遵循其他最佳实践的应用程序来说，它是一种创可贴。例如，服务可能正在使用本地时间戳而不是基于 UTC 的时间戳写入日志文件，从而在夏令时回退过渡期间产生歧义。将服务器的时区设置为 UTC 将修复该应用程序。然而，真正的解决办法是让应用程序一开始就使用 UTC 进行日志记录。
服务器端代码，包括网站，不应该期望服务器的本地时区是特定的。
在某些语言中，本地时区很容易渗入应用程序代码。例如，DateTime.ToUniversalTime.NET 中的方法将本地时区转换为UTC，该DateTime.Now属性返回本地时区的当前时间。此外，DateJavaScript 中的构造函数使用计算机的本地时区。像这样的例子还有很多。练习防御性编程很重要，避免使用任何使用计算机本地时区设置的代码。
使用本地时区为客户端代码保留，例如桌面应用程序、移动应用程序和客户端 JavaScript。
将您的服务器设置为 UTC，并确保它们都配置为 ntp 或等效的。
UTC 避免了夏令时问题，不同步的服务器可能导致无法预测的结果，需要一段时间才能诊断。
处理存储在 FAT32 文件系统中的时间戳时要小心 - 它始终保存在本地时间坐标中（包括 DST - 请参阅msdn 文章）。被那个烫伤了。
另一件事是，确保服务器应用了最新的夏令时补丁。
去年我们遇到过这样一种情况，即使我们使用的是基于 UTC 的系统，北美用户在三周内的时间都持续减少一小时。
最终结果是服务器。他们只需要应用最新的补丁（Windows Server 2003）。
DateTimeZone::listAbbreviations()输出这个 PHP 方法返回一个包含一些“主要”时区（如 CEST）的关联数组，这些时区本身包含更具体的“地理”时区（如欧洲/阿姆斯特丹）。
如果您使用这些时区及其偏移量/夏令时信息，那么了解以下内容非常重要：
似乎每个时区的所有不同偏移量/DST 配置（包括历史配置）都包括在内！
例如，Europe/Amsterdam 可以在此函数的输出中找到六次。两次出现（偏移量 1172/4772）是用于 1937 年之前的阿姆斯特丹时间；两个 (1200/4800) 用于 1937 年至 1940 年间使用的时间；和两个 (3600/4800) 是自 1940 年以来使用的时间。
因此，您不能将此函数返回的偏移量/DST 信息视为当前正确/正在使用！
如果您想知道某个时区的当前偏移量/夏令时，您必须执行以下操作：
<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>
如果您碰巧维护了在 DST 活动状态下运行的数据库系统，请仔细检查它们是否需要在秋季过渡期间关闭。Mandy DBS（或其他系统）不喜欢在（本地）时间两次通过同一点，这正是您在秋天倒转时钟时发生的情况。SAP 已经通过一种（恕我直言）解决方法解决了这个问题——他们没有让时钟倒转，而是让内部时钟以正常速度的一半运行两个小时......
您使用的是.NET 框架吗？如果是这样，让我向您介绍 .NET 3.5 添加的DateTimeOffset类型。
此结构同时包含 aDateTime和 Offset ( )，它指定实例的日期和时间与协调世界时 (UTC)TimeSpan之间的差异。DateTimeOffset
DateTimeOffset.Now静态方法将返回一个由DateTimeOffset
当前（本地）时间和本地偏移量（在操作系统的区域信息中定义）组成的实例。
DateTimeOffset.UtcNow静态方法将返回一个
包含DateTimeOffsetUTC 当前时间的实例（就像您在格林威治一样）。
其他有用的类型是TimeZone和TimeZoneInfo类。
对于那些在.NET上苦苦挣扎的人，看看使用DateTimeOffset和/或TimeZoneInfo是否值得你花时间。
如果您想使用IANA/Olson 时区，或者发现内置类型不足以满足您的需求，请查看Noda Time，它为 .NET 提供了更智能的日期和时间 API。
这是我的经验：-
（不需要任何第三方库）
只是想指出两件看起来不准确或至少令人困惑的事情：
始终根据不受夏令时影响的统一标准持续时间。GMT 和 UTC 已被不同的人提及，但似乎最常提及 UTC。
对于（几乎）所有实际计算目的，UTC 实际上是 GMT。除非您看到带有小数秒的时间戳，否则您正在处理的是 GMT，这使得这种区别变得多余。
存储时间戳时包括本地时间偏移量（包括 DST 偏移量）。
时间戳始终以 GMT 表示，因此没有偏移。
Tom Scott 在 YouTube上 Computerphile 频道上关于时区的视频也对该主题进行了很好且有趣的描述。示例包括：
仅举一个例子来证明处理时间是所描述的巨大混乱，并且您永远不能自满。在本页的几个地方，闰秒被忽略了。
几年前，Android 操作系统使用 GPS 卫星获取 UTC 时间参考，但忽略了 GPS 卫星不使用闰秒这一事实。直到新年前夜出现混乱，当时苹果手机用户和安卓手机用户的倒计时时间间隔大约为 15 秒，没有人注意到这一点。
我想它已经被修复了，但你永远不知道这些“小细节”什么时候会再次困扰你。
实际上，kernel32.dll 不会导出 SystemTimeToTzSpecificLocation。但是它会导出以下两个：SystemTimeToTzSpecificLocalTime 和 TzSpecificLocalTimeToSystemTime...
永远不要只依赖像这样的构造函数
new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)
当由于 DST 导致某个日期时间不存在时，它们可能会引发异常。相反，构建您自己的方法来创建此类日期。在它们中，捕获由于 DST 而发生的任何异常，并使用转换偏移量调整所需的时间。根据时区，DST 可能发生在不同的日期和不同的时间（即使是巴西的午夜）。
struct tm存储的示例包括 FAT32 和 C 语言。¹¹ 某些实现struct tm确实存储了 UTC 偏移量，但这还没有成为标准。
在处理数据库（特别是MySQL，但这适用于大多数数据库）时，我发现很难存储 UTC。
我发现将服务器日期时间存储在数据库中更容易，然后让数据库在 SQL 语句中将存储的日期时间转换回 UTC（即 UNIX_TIMESTAMP()）。之后，您可以在代码中使用日期时间作为 UTC。
如果您对服务器和所有代码有 100% 的控制权，最好将服务器时区更改为 UTC。