（这是一个关于 UI 的问题，而不是实现它所需的技术）
向用户显示在不同时区发生的事件的时间的最清晰方法是什么？您的“普通”用户是否了解 UTC 和时区？
我们捕获本地时间和 UTC 偏移量并将其存储在数据库 (SQL 2008 DateTimeOffset) 中，用于不同时区发生的事件。用户也处于不同的时区。
我将在下面提出几个答案，以便对它们进行评级，但我会很感激其他建议。
编辑：我想避免在用户的时区显示时间。不同时区的用户将讨论相同的事件，如果他们位于不同时区的本地，就会产生混淆。
编辑：我想让这个问题变得通用，希望对更多人有用，但对于某些特定的上下文，这是一个用于跟踪包裹的 Web 应用程序（想想 FedEx）。包裹将跨越时区。客户支持在英国，但收件人可能在其他地方。
尝试使用旧式新闻编辑室图形，将时钟标记为“纽约”、“伦敦”、“东京”，然后是“巴布亚新几内亚”或特定观众所在的任何位置。您可以使时钟模拟或数字或两者兼而有之。
没有人会对此感到困惑，而我认为大多数人并不真正了解 GMT+7（或其他）的含义。
像这样显示当地时间和偏移量 15:18 GMT+1
用时区缩写显示它
代替
15:18 GMT+1
显示为中欧时间
15:18 CET
人们更习惯于看到自己的时区
策略应该是 UI 中的时间——当向用户显示或输入时——在用户自己的时区中。
另一方面，在应用程序中，即在 Ruby 代码和数据库中，时间始终保持在 UTC 时区中。
然后，您的工作就是允许用户选择一个时区，然后根据需要在该时区和 UTC 时区之间来回转换。
本文说明了如何在 Rails 环境中执行此操作。
这意味着能够检索用户时区或将该时区存储在“用户”表中。
你提到包裹。物流的惯例是始终显示当地时间，这就是 UPS 等在其跟踪数据中的状态历史记录中显示的内容。
如果本地时间不是当前用户的时区，那么我会考虑用时区注释时间，例如09:00 (Europe/Amsterdam)。
请注意，地名比缩写更好，这可能是模棱两可的。由您决定是否告诉用户时间在哪里更有用，或者与他们的时区有什么不同。
避免该问题的一种方法是仅使用相对时间，例如4 hours ago。
我认为如果没有特定的应用程序，这个问题就无法明确回答。例如，在同一时区的所有用户的 Intranet 应用程序中，您通常可以完全省略时区。对于股票市场应用程序，您可能希望将时间与市场的时区相关。对于社交网络应用程序，您可能希望将时间设置为相对于用户的时区。我认为适用的一般原则是：
正如其他人所提到的，我认为如果应用程序是特定的或本地的，那么您可以省略时区，或做出其他假设。
如果它是全局的，那么您希望一致地存储数据（始终为 UTC），然后转换为显示。此外，您可能希望让用户指定他/她的时区，并且可能还指定日期和时间格式；要么提供几个静态选项，要么赋予它们指定格式字符串的全部权力，如果它们足够先进的话。
如果您不想为用户提供选项，那么简单的 HH:MM TZ 或 HH:MM GMT+/-H 似乎就足够了？或者您甚至可以只显示服务器本地的时间，然后在脚注或常见问题解答中，说“所有时间都是 PST”或其他任何时间。
作为用户，我更喜欢最大的可配置性，但我想我是有偏见的，作为一名程序员。
我喜欢 GMT+offset（假设 offset“通常”是用户的时区）。作为额外的线索，提供一个工具提示，列出该时区中的一些城市（每个半球一个），或者提供指向更详细解释时区的某个页面的超链接。
您所描述的是页面查看者正在支持客户的情况。
所以我建议设计关注客户的角度。因此，默认或主要显示方法应该是客户的当地时间。如果您使用电子邮件或 IM，您应该有某种用户目录作为来源。如果你在打电话，那么来电显示可以作为时间转换的依据。
这也是该软件仅是支持产品的一部分而不是整个支持产品的一个示例。显示屏应允许轻松切换到其他时区，并且电话代表应始终接受培训，以便在提供任何基于时间的信息之前询问他们所在的时区。
它还应该有一个选项来显示到达点的当地时间。这使您能够以无缝和有效的方式与客户交谈：
CU: "When will it arrive?"
CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm".
CU: "I am traveling in Chicago right now. Can you tell me when I should check back?"
(Phone rep taps a "CST" button on the screen, and the displays convert.)
CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."
这是一个非常上下文敏感的情况。我想以 postos 和 tvanfosson 的建议为基础。我认为不需要城市和国家的名称，除了帮助人们设置他们的当地时间，也许在对话框中设置时间，当他们只知道所需的当地时间时（不压倒/分散注意力的巨大挑战）对他们来说很混乱的用户）。
如果位置与时间相关联，则该位置的日期和时间通常是合适的（例如，当谈到市场收盘、事件、旅行到达和离开等时）。我赞成工具提示可用于将其转换为 (1) gmt 和 (2) 正在查看界面的用户的明显本地时间的想法。偏移量也很有用，还有涉及午夜过境点的日期。
我也同意时区应该明确表明它可能不是当地时间。此外，即使在没有时区的情况下显示本地时间，我认为工具提示仍然很重要。（特别是当携带笔记本电脑旅行的人可能会保留他们的家乡时区设置。）
对细节的额外关注：处理夏令时、夏令时等的时移，以及它们在位置之间的差异（不是每个地方都有夏令时，不是每个地方都同时进行更改）和时间点之间的差异（进入尤其是未来）。
最好的办法是将所有日期/时间信息存储在 UTC 中，然后显示与用户时间偏移的时间。.NET 对此提供了各种支持——大多数其他环境也为此提供了支持。早上 7 点在伦敦输入数据的人应显示为美国东部时间凌晨 1 点或凌晨 2 点。关于 UTC 最好的部分是，当您在没有夏令时的地方时，它可以避免所有带有夏令时或缺乏夏令时的麻烦事情，例如。韩国、印度与北美的新抵消。
我喜欢 24 小时制，例如美国东部夏令时间 15:30，但我相信有些人可以在 12 小时制下工作。确保将其作为一个选项。
多年来，“小型”应用程序突然在全国范围内（在美国，5 或 6 个时区）或全球范围内被咬了好几次，如果可能，我总是将日期时间数据存储在 UTC 中。
正如许多其他帖子所指出的那样，问题就变成了显示。
如果显示日期/时间，并且它与当前用户的位置（和区域设置）相关，则以用户的本地时间显示。
如果要显示多个日期/时间并且它们与不同的位置（可能是不同的语言环境）相关，我发现用户更喜欢以 12 小时格式查看在该位置的时区中显示的时间。
想想如何打印机票（至少在美国）——出发和到达时间显示在出发城市和到达城市的时区。最好的路线有一个“总旅行时间”或显示的持续时间。
好的，所以您想为用户显示区域设置格式的数据：您如何确定区域设置？对于 Web 应用程序，虽然大多数 HTTP 标头中都存在语言环境，但您不能总是相信用户机器上的语言环境设置正确。因此，我们几乎总是要求用户设置一个配置文件，其中包含一些我们可以从中确定区域设置（邮政编码、城市/州/国家等）的数据，或者输入一些让我们知道在哪里的信息用户实际驻留（对于 Web 应用程序或“本机”应用程序）
自从通过 ip 地址进行地理定位变得广泛可用以来，我不必实现这一点，但这也不一定准确。
请注意，当我处理这些应用程序时，我的个人设置几乎总是以 24 小时格式、UTC、ISO8601 结束，这样我就知道向我显示什么时间，而不管用户在哪里。
始终以 UTC 显示时间
注意我不同意这一点。我只是将其添加为投票选项。